buy-something team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

Over the past few days we have completed the state transitions and run
integration tests with Michael and Gary using software center client
and the staging versions of the identity provider, payment service and
launchpad. Unfortunately we haven't yet been able to get the
authentication details for the software-center-agent on staging, so
the new subscriptions have followed the following state transitions:

{{{
2010-07-22 09:11:55.828550 New -> PaymentInitiated:
2010-07-22 09:13:39.828839 PaymentInitiated -> PaymentAuthorized:
Payment status returned by payment service is AUTHORISED.
2010-07-22 09:13:43.090885 PaymentAuthorized -> FailedLPSubscription:
HTTP Error 401: Unauthorized
2010-07-22 09:13:45.256722 FailedLPSubscription -> NoPayment: Payment
cancelled successfully.
2010-07-22 09:13:45.647519 NoPayment -> Cancelled:
}}}

but it still enabled us to verify the integration with the client
(using the above integration test for the failure scenario, and the
stubbed version for the success scenario until we have the staging LP
access).


Current discussion items
====================

Regarding the authentication details for software-center-agent on
staging, I've been chatting with the losas, and have just sent an RT
to launchpad@xxxxxxxxxxxxxxxx - cc'ing Rick - with all the details so
that it gets tracked while I'm working from the train today.

The design of the payment page - it would be great to get this as
minimal as possible, so Michael and Gary can decide whether they can
embed the webkit window, or keep it as a separate window (as they are
doing currently). Also, Rick was wondering whether the design team
will be involved in finalizing the payment form.

Michael, Gary and I are discussing improvements to the interface
between the client and the agent. Currently when the payment is
confirmed, the user is redirected to a page on the agent that
continues to display the status of the subscription purchase until it
is either complete or cancelled, at which time the client sees the
title change event. But this is not optimal (for example, the user
closes the window - the client would need to check the subscription
via the API anyway). For this reason, we're thinking of changing this
interface so that when the payment is confirmed and the user is
redirected back to the agent, the agent immediately does a
title-change event so that the client gets the subscription ID. The
client can then check the subscription to watch the status update
itself (and give more integrated feedback to the user).

The other interface change being considered is the initiation of a new
purchase. Currently this happens via a GET request to the agent, which
is redirected to the login service before the agent then redirects
them to a specific url on the payment service. If the client instead
authenticated (using either mvo's auth widget that he's built, or the
full app that we found out Natalia from online-services is creating
for U1 which will also enable account creation etc.,), it would mean
that the client could create the subscription using the agent API and
get the payment url itself - enabling better handling of errors in the
initial subscription creation (ie. user doesn't authenticate, agent is
unavailable etc.)

Happy hacking!
-Michael