Hi Michael! On 06/17/2010 07:12 AM, Michael Nelson wrote: > Yep, I'll hope to get started next week. Where can I read the API > documentation for the payment gateway that's being implemented? Also, > I assume we'll need a private project (or private branches) if the > code is going to be exposing the API for the payment gateway, or is > this ok being public (as long as the real config options etc., are not > stored in the branch of course). > > -Michael
Last week in #payments Ricardo Kirkner gave an overview of the payments API to mvo and me. We found it very helpful in getting us started thinking about the API and how to use it so I've attached the log of our session in hopes it will be useful to you as well. Please be sure to ping me anytime (or mvo - he's back next week) if there's anything I can help with. Also, Ricardo and the other good folks in #payments are a great resource so you could pop in there anytime you need to as well. Thanks! Gary
Jun 08 11:50:59 <ricardokirkner> ok, tremolux are you ready? Jun 08 11:52:07 <tremolux> ricardokirkner: yep! lesgo :) Jun 08 11:52:18 <ricardokirkner> cool Jun 08 11:52:41 <ricardokirkner> we have a payments server set up here: http://ec2-174-129-157-206.compute-1.amazonaws.com/ Jun 08 11:53:00 <ricardokirkner> I will walk you through the most basic flow first Jun 08 11:53:05 <ricardokirkner> so go there + /test/new Jun 08 11:53:18 <ricardokirkner> this will request a new payment to be created Jun 08 11:53:33 <mvo> ok, I'm there now Jun 08 11:53:37 <mvo> and I see "checkout" Jun 08 11:53:43 <ricardokirkner> exactly Jun 08 11:54:08 <ricardokirkner> this is a test consumer we are using, so in this case, what you are shown is decided by the consumer Jun 08 11:54:12 <mvo> (silly?) question: does this have to be done with a browser or can I use the clientlib from your source too? Jun 08 11:54:36 <ricardokirkner> mvo, of course you can use (and should most probably) use the clientlib Jun 08 11:55:21 * mvo hopes the Pepperoni pizza is vegetarian Jun 08 11:56:02 <ricardokirkner> mvo as said, the idea is for you guys to use the clientlib Jun 08 11:56:22 <ricardokirkner> though I wanted to do a quick walkthrough in case you weren't familiarized with the api Jun 08 11:56:31 <mvo> ok Jun 08 11:56:45 <ricardokirkner> but we can skip it if you are good with it Jun 08 11:57:09 <ricardokirkner> lets get over it quickly Jun 08 11:57:22 <tremolux> sure, that'd be good Jun 08 11:57:32 <mvo> no skipping :) Jun 08 11:57:36 <ricardokirkner> once you got the response from the server, the consumer decided to show you the checkout link, this is so because the next step requires human intervention Jun 08 11:57:37 <mvo> I need all the info I can get Jun 08 11:57:53 <ricardokirkner> so if you hit the checkout link you'll get a form presented where you have to enter the credit card info Jun 08 11:57:53 <tremolux> :) Jun 08 11:58:06 <ricardokirkner> currently we are missing two things here right now Jun 08 11:58:31 <ricardokirkner> 1) openid integration (which is about to be merged in) so that before getting the form the user has to authenticate itself using openid Jun 08 11:59:07 <ricardokirkner> 2) a form for selecting the payment method (bibit -- currently the only method implemented -- or paypal -- in the future) Jun 08 11:59:21 <ricardokirkner> after the user logs in and selects the payment method he will get redirected to the correct page Jun 08 11:59:25 <mvo> I got a openid prompt when clicking on checkout Jun 08 11:59:36 <tremolux> ricardokirkner: welllll, I just hit the openid auth page actually Jun 08 11:59:43 <ricardokirkner> ah, yes Jun 08 11:59:43 <ricardokirkner> right Jun 08 11:59:47 <tremolux> ricardokirkner: signed in and now I see the form, cool! Jun 08 11:59:54 <ricardokirkner> I forgot... in this setup it was already integrated :) Jun 08 12:00:02 <mvo> :) Jun 08 12:00:02 <ricardokirkner> but not in trunk Jun 08 12:00:12 <ricardokirkner> cool Jun 08 12:00:27 <ricardokirkner> so when you hit submit and confirm the payment Jun 08 12:00:37 <ricardokirkner> we communicate with the real backend and do the magic Jun 08 12:00:54 <ricardokirkner> and then we'll try to contact the consumer using a callback url Jun 08 12:01:08 <ricardokirkner> so, this was very high level what the user sees Jun 08 12:01:20 <ricardokirkner> I would advise you guys to get the code and we can go a bit deeper Jun 08 12:01:34 <ricardokirkner> the branch is lp:canonical-payment-service Jun 08 12:02:11 <mvo> I have that at r104 Jun 08 12:03:39 <ricardokirkner> we changed a lot lately :) Jun 08 12:03:42 <ricardokirkner> and we'll change a lot more Jun 08 12:03:48 <ricardokirkner> but 104 is the latest I think Jun 08 12:04:12 <mvo> ok Jun 08 12:04:21 <ricardokirkner> lets wait for tremolux Jun 08 12:04:48 <tremolux> bah, not my day, why can't I get the branch? Jun 08 12:05:08 <mvo> maybe your are not in ~isd-hackers (or whatever the group is called?) Jun 08 12:05:22 <ricardokirkner> or maybe the url I gave you was wrong Jun 08 12:05:30 <ricardokirkner> try with lp:~canonical-isd-hackers/canonical-payment-service/trunk Jun 08 12:05:46 <ricardokirkner> the project has no default branch yet Jun 08 12:05:55 <ricardokirkner> will fix that in a while Jun 08 12:06:14 <tremolux> that's it, thx Jun 08 12:06:16 <tremolux> got it Jun 08 12:06:43 <ricardokirkner> ok, lets look at testconsumer/views.py Jun 08 12:06:44 <tremolux> (mvo has probably eaten all the pizza by now) Jun 08 12:07:10 <mvo> got it Jun 08 12:07:13 <tremolux> yep Jun 08 12:07:13 <ricardokirkner> the consumer is what you guys are going to implement :) Jun 08 12:07:29 <ricardokirkner> ok, here you have a view for each api call Jun 08 12:07:39 <ricardokirkner> init_checkout is the one called when we did /test/new Jun 08 12:08:01 <ricardokirkner> it connects to the api using PaymentServiceClient Jun 08 12:08:17 <ricardokirkner> and then asks for the new payment Jun 08 12:09:14 <ricardokirkner> then the user gets a link, to get the form directly Jun 08 12:10:00 <ricardokirkner> and when we process the payment we call the checkout_complete_url (which was the last step) Jun 08 12:10:11 <ricardokirkner> so its very simple actually Jun 08 12:10:16 <ricardokirkner> you have a way to request a new payment Jun 08 12:10:50 <ricardokirkner> and when the payment is about to be processed we call you so you can choose to abort or whatever Jun 08 12:11:02 <ricardokirkner> I will talk more on this a bit later Jun 08 12:11:19 <ricardokirkner> then you also have api calls to capture a payment (which is to effectively make the payment) Jun 08 12:11:21 <ricardokirkner> to cancel it Jun 08 12:11:47 <ricardokirkner> to renew it (this is used to repeat a previous payment optionally changing some of its attributes) Jun 08 12:11:57 <ricardokirkner> to refund a payment that was already done Jun 08 12:12:01 <ricardokirkner> how are we going so far? Jun 08 12:12:56 <tremolux> yeah, this is good Jun 08 12:13:18 <mvo> so far so good Jun 08 12:13:46 <ricardokirkner> cool Jun 08 12:13:52 <ricardokirkner> the other thing I wanted to mention is the following Jun 08 12:14:19 <ricardokirkner> so far we are using a checkout_complete_url to communicate with the consumer, but we where thinking this might not work entirely for you guys Jun 08 12:14:30 <ricardokirkner> as the desktop app might be behind a firewall or something Jun 08 12:15:03 <ricardokirkner> so we need to come up with some way of letting you know when the payment is ready to be captured, Jun 08 12:15:23 <ricardokirkner> any ideas? preferences? Jun 08 12:15:32 <ricardokirkner> questions? Jun 08 12:15:44 <mvo> I'm not getting the big picture yet, while I be able (as a software-center UI client) to complettely stay within the api? or will I have to show some browser/webkit etc to get the payment info (credit card etc) Jun 08 12:15:50 <mvo> s/while/will/ Jun 08 12:16:30 <ricardokirkner> mvo, you will have to show some browser Jun 08 12:16:44 <ricardokirkner> actually, not really Jun 08 12:16:45 <mvo> firewall> well, assum the checkout_complete_url is something we just do a GET on ? if so, I would assume that if the users firewall can connect to the payment service, then he can connect to this url as well Jun 08 12:16:52 <ricardokirkner> this depends on you I think Jun 08 12:17:10 <ricardokirkner> you could gather all the data yourself, but then you would have to do an http request on our server as if you were the suer Jun 08 12:17:10 <ricardokirkner> user Jun 08 12:17:18 <mvo> ok Jun 08 12:17:31 <tremolux> ah Jun 08 12:17:33 <mvo> well, I think showing a browser is fine (at least for now) Jun 08 12:17:39 <ricardokirkner> the checkout_complete_url is something WE have to be able to do a GET on :) Jun 08 12:17:42 <mvo> I just wanted to be sure that I get the workflow Jun 08 12:17:48 <mvo> oh Jun 08 12:17:59 <ricardokirkner> the workflow is basically Jun 08 12:18:11 <ricardokirkner> a) you get all the info you need from the client regarding what you want to buy Jun 08 12:18:28 <ricardokirkner> b) you request a payment from us and get a url in response Jun 08 12:18:44 <ricardokirkner> c) you direct your user to that url and let him enter all the payment data Jun 08 12:19:08 <ricardokirkner> d) we call you on the checkout_complete_url you provided us and await further action on your side Jun 08 12:19:20 <ricardokirkner> e) ideally, you call us via the api to capture (confirm) the payment Jun 08 12:19:54 <tremolux> ricardokirkner: so, as far as server-side is concerned, it doesn't matter that we send up for payment? that all comes from us Jun 08 12:20:02 <ricardokirkner> phanatic, achuni can you please confirm I'm not saying this wrongly? ^^ Jun 08 12:20:38 <mvo> d) is doing to be a problem in a lot of setups, it would be better if the client can POST or GET to some url that you provide Jun 08 12:20:53 <mvo> thanks for the overview, that is much clearer now for me :) Jun 08 12:22:04 <ricardokirkner> mvo, there are a few errors there, I think... sorry :) I'm clearing it up and I'll explain again in a sec Jun 08 12:23:14 <mvo> ricardokirkner: ok, I just got a call for dinner, so I have to leave for now. can we continue tomorrow maybe? Jun 08 12:23:58 <mvo> ricardokirkner: I will read irc scrollback so if you put something in I will read it Jun 08 12:24:05 <ricardokirkner> mvo, I'll finish pasting the correct flow here so you can read it later (or tomorrow) and we can pick up again with questions on your side, ok? Jun 08 12:24:21 <mvo> sounds great Jun 08 12:24:24 <mvo> thanks for your help Jun 08 12:24:26 <mvo> and for the server setup Jun 08 12:25:01 <tremolux> ricardokirkner: this is really cool stuff, thanks a lot Jun 08 12:25:38 <ricardokirkner> tremolux, np... I'd say give the testconsumer and the clientlib a good look, as it will help you out understand the api from the consumer point of view Jun 08 12:25:44 <achuni> ricardokirkner: that's the correct workflow, yes Jun 08 12:27:34 --- beuno-lunch is now known as beuno Jun 08 12:29:50 <tremolux> ricardokirkner: oops, my desktop meeting is starting, I'll read through the code as you suggest, thanks again! Jun 08 12:30:03 <ricardokirkner> sure Jun 08 12:30:16 <tremolux> ricardokirkner: I assume we are safe to play using the test server based on testconsumer, etc.? Jun 08 12:30:55 <ricardokirkner> I would say yes Jun 08 12:31:11 <ricardokirkner> let me know if you find any bugs or have any issues Jun 08 12:31:36 <tremolux> ricardokirkner: thanks, cool! Jun 08 12:34:27 <phanatic> achuni: did you point the ec2 instance at bibit's test system, or is it using the mock of bibit? Jun 08 12:35:02 <achuni> phanatic: it's using bibit's test system Jun 08 12:35:05 <achuni> why? Jun 08 12:35:20 <phanatic> just asking Jun 08 12:35:31 <phanatic> did you edit the email address? Jun 08 12:39:26 <achuni> phanatic: yup Jun 08 12:39:48 <achuni> phanatic: still, I haven't received any emails about that yet :-/ Jun 08 12:40:07 <ricardokirkner> mvo, tremolux workflow description take 2 Jun 08 12:40:07 <ricardokirkner> payments normal workflow Jun 08 12:40:07 <ricardokirkner> a) consumer gets all the info regarding what the user wants to buy Jun 08 12:40:07 <ricardokirkner> b) consumer request a payment from paymentservice using the api and get a url in response Jun 08 12:40:07 <ricardokirkner> c) consumer directs the user to that url and let him enter all the payment data (credit card info, etc) Jun 08 12:40:07 <ricardokirkner> d) payment service sends the consumer a notification informing of the payment authorization status to the url specified by notification_url (this is per consumer and required). Jun 08 12:40:10 <ricardokirkner> e) if authorization was successful, it also redirects the user (HTTP 302) to the url specified by checkout_complete_url (this is per-payment and optional) Jun 08 12:40:13 <ricardokirkner> f) consumer requests payment capture (confirm) using the api Jun 08 12:40:47 <ricardokirkner> achuni, phanatic I told mvo and tremolux to use the ec2 instance to play around Jun 08 12:41:04 <achuni> ricardokirkner: sure Jun 08 12:41:32 <achuni> ricardokirkner: it has "issues" that will not allow you to complete a payment still. Jun 08 12:41:47 <achuni> but you can get almost all the way there Jun 08 12:41:50 <ricardokirkner> yes, I told them to tell us of any issues they find Jun 08 12:41:58 <tremolux> achuni, ricardokirkner: but it's safe to go through the workflow (as much as possible) Jun 08 12:42:17 <achuni> tremolux: yes, you won't break anything or lose money :) Jun 08 12:42:39 <tremolux> achuni, ricardokirkner: hehe, you got my concern perfectly :D Jun 08 12:42:46 <phanatic> achuni: that's not good news :/ Jun 08 12:42:57 <achuni> phanatic: I know Jun 08 12:43:10 <ricardokirkner> tremolux, you can look at bibit/testing/testdata.py Jun 08 12:43:14 <achuni> phanatic: debugging now Jun 08 12:43:22 <ricardokirkner> there you'll find dummy credit card numbers to play with Jun 08 12:43:37 <tremolux> ricardokirkner: awesome, thx Jun 08 12:44:15 <tremolux> thanks a lot, you guys are really rocking with this Jun 08 12:55:17 <achuni> jdo: are you around? **** BEGIN LOGGING AT Tue Jun 8 12:59:17 2010 Jun 08 14:14:57 --> You are now talking on #payments Jun 08 14:36:44 <mvo> ricardokirkner: if you are still around, I got one more question. when the transaction was done I need to hand some sort of "proof" that it was done to LP so that the LP server side can check if the user really did the payment. alternatively LP could request that or the system send it to LP. but in some way such a "proof" is needed. what is the best way to archive that? Jun 08 14:39:25 <ricardokirkner> mvo, I'm not sure what you need. when you capture the payment, you can be sure it has been debited to the user. the api request returns a success code, so that if it returns ok, it means it was done ok Jun 08 14:39:45 <ricardokirkner> you also have your payment id which you can use to refer later to the payment that was done Jun 08 14:40:27 <mvo> ricardokirkner: aha, I guess the payment id is the bit that I was looking for. with that ID launchpad could verify that the user actually did pay for the software, correct? Jun 08 14:41:13 <mvo> ricardokirkner: when testing against the ec2 system, is there a valid (but fake) credit card that can be used? or will it accept any number there? Jun 08 14:42:13 <ricardokirkner> eventually with that id LP could (using the api) request that payment details on the payment service (i.e. us). we would return some status on the payment I guess (I think this api call is currently disabled, but we could eventually add something like this) Jun 08 14:42:32 <ricardokirkner> mvo, look at bibit/testing/testdata.py there you have a bunch of data you can use (which is dummy data) Jun 08 14:42:47 <mvo> ricardokirkner: I ask about the payment ID because it will be software-center doing the payment. then it goes to launchpad and tells it that the payment has been done. but then launchpad must have some sort of verification that the user has done it for real and is not just pretending to Jun 08 14:42:56 <mvo> ricardokirkner: testing> thanks :) Jun 08 14:44:19 <mvo> ricardokirkner: do you want a bugreport about the "verify-that-the-user-actually-payed" feature? or is that planned anyway and no need for a additional report? Jun 08 14:44:37 <ricardokirkner> mvo, please add a bug (so I don't forget it) Jun 08 14:44:54 <ricardokirkner> you probably want some api call to get the payment state for a given payment Jun 08 14:45:00 <ricardokirkner> or to query some other details Jun 08 14:46:52 <jdo> achuni, get it working? Jun 08 14:47:29 --- teknico is now known as teknico_away Jun 08 14:47:37 <achuni> jdo: a few tests are failing, but they're tests we've added since we started working on it Jun 08 14:47:56 <achuni> jdo: for example, with the mock backend you could process a renewal without ever processing the parent payment it seems **** ENDING LOGGING AT Tue Jun 8 14:48:08 2010
_______________________________________________ Mailing list: https://launchpad.net/~buy-something Post to : [email protected] Unsubscribe : https://launchpad.net/~buy-something More help : https://help.launchpad.net/ListHelp
