← Back to team overview

canonical-isd-hackers team mailing list archive

problem with payment service

 

Ricardo,

I wanted to inform you of some problems I see in the current payment service as it does not meet all of our
requirements. These are pretty serious issues so we need to discuss them ASAP.

Perhaps I should spell out the specific workflows we have to identify the differences. A completely new subscription
works with Ubuntu Pay so I'll skip this.

*Increasing Qty of an existing subscription*
The user's subscription is changed in place and the renewal/expiration dates remain the same (only the price and qty
change). The user is immediately billed for a prorated amount for the price difference for the rest of the month. And
the monthly/annual price for the subscription remains the same. This currently works with Ubuntu Pay, however the user
is required to enter their payment details again. In Ubuntu One, the payment is made using a PayAsOrder so the user does
not have to enter this information again and they are billed without any further interaction.

*Decreasing Qty of an existing subscription*
The user's subscription is changed in place and the renewal/expiration dates remain the same (only the price and qty
change). The user is credited for the price difference for the rest of the month. On the next billing period, the
subscription is renewed using any credits they have. Payments are not made until the credits are exhausted.

*Changing the subscription from one option to another*
The user's existing subscription is immediately cancelled and they are credited for the unused amount. A new
subscription is created for the new service. Credits from the cancelled subscription are used to make the first payment
as well as any renewal payments until all credits are exhausted. For example, if a user changes from an Annual to a
Monthly subscription option, they may have enough credits to use the service for a few months before a payment is made.
Note, currently this only involves changing between monthly & annual subscriptions, but we should not focus on this as
the only difference as we have had to use this option when we changed users from the 50GB plan to the 20GB plan for example.



Other things of note:

* Currently we are sending currency along with the payment. It is inappropriate for Ubuntu One to be specifying currency
since this is a payment related property. Previously we discussed being able to specify prices in a dict for each
currency price we have caclulated. Can we still do this?

* As I mentioned today, the payment data structures sent to the payclient inconsistent.





Follow ups