buy-something team mailing list archive

[Gary Lasker <gary.lasker@xxxxxxxxxxxxx>]

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