Concept
Like mobile applications, the integrated purchase of a subscription service allows the customer to make adjustments to his subscription or increase his consumption in just a few clicks. It’s one of the best ways to increase revenue by reducing customer interactions.
One of your users wishes to perform an action that may trigger a additional cost.
Example (to be declined according to what you charge in your department) :
- addition of a collaborator
- electronic signature of a document
- activation of 24-hour support
In a single call to the ProAbono API, you recover the cost of the modification as well as the new subscription fee, depending on the subscription of this user. This data allows you to build a notification for the user to confirm his decision. This notification is mandatory and prevents the customer from contesting his future invoice.
If the user presses the ‘confirm’ button, you confirm this modification by API to ProAbono, which takes care of automating the invoicing part. The main benefit is that the user does not need to go to the ‘My subscription’ section of your application to make this modification, which makes the user experience more fluid.
Other benefits
If the user has unlimited access or if the modification does not result in an additional cost, the API call returns a rate of 0, so there is probably no need to ask for confirmation. If the modification is paying, the call will identify the following cases:
- the user does not have a registered means of payment
- the user has too many unpaid invoices and needs to regularize his old invoices before continuing
- the user does not have access to this feature
Depending on the case, it is recommended to display a message with a link allowing him to register his payment method or to change his offer.
Process
1/ Recover the cost of the modification
The call to make all these checks and to calculate the rate of a possible overcharge is Compute pricing usage.
Example :
{
POST /v1/Pricing/Usage?referenceCustomer=cust_1&referenceFeature=team-members
"Increment": 2,
"DateStamp": "2018-12-31T15:31:00.00Z",
"NextTerm": true,
}
Result :
{
"IdSegment": 7,
"IdCustomer": 406146,
"IdSubscription": 286407,
"IdFeature": 6915,
"ReferenceSegment": "dev",
"ReferenceCustomer": "cust_1",
"ReferenceFeature": "team-members",
"LabelLocalized": "Net à payer",
"PricingLocalized": "8.97 €",
"Currency": "EUR",
"AmountSubtotal": 748,
"AmountTotal": 897,
"DatePeriodStart": "2019-01-02T15:33:00.00Z",
"DatePeriodTerm": "2019-01-31T15:29:27.00Z",
"Details": [...],
"NextTerm": {
"IdSegment": 7,
"IdCustomer": 406146,
"IdSubscription": 286407,
"ReferenceSegment": "dev",
"ReferenceCustomer": "cust_1",
"LabelLocalized": "Coût de l'abonnement après modification",
"PricingLocalized": "220.78 €",
"Currency": "EUR",
"AmountSubtotal": 18399,
"AmountTotal": 22078,
"DatePeriodStart": "2019-01-31T15:29:27.00Z",
"DatePeriodTerm": "2019-02-28T15:29:27.00Z",
"Details": [...]
}
}
ProAbono automatically provides the wording and the amount localized in the client’s language, for the net cost to be paid and the cost of the subscription after modification (in the sub-object ‘NextTerm’).
2/ Confirmation of change
The call to confirm a change is Update usage. The content (body) of the call is strictly identical to the previous call.
Example :
POST /v1/Usage?referenceCustomer=cust_1&referenceFeature=team-members
{
"IdSegment": 7,
"IdFeature": 6915,
"IdCustomer": 406146,
"IdSubscription": 286407,
"ReferenceSegment": "dev",
"ReferenceFeature": "team-members",
"ReferenceCustomer": "cust_1",
"TypeFeature": "Limitation",
"QuantityIncluded": 3,
"QuantityCurrent": 9,
"DatePeriodStart": "2018-12-31T15:29:27.00Z",
"DatePeriodEnd": "2019-01-31T15:29:27.00Z"
}
If successful, the result is use after adjustment.
3/ Additional cases (to be managed)
The /v1/Pricing/Usage call also allows to detect several cases where the modification is not allowed. It is desirable to manage these cases to allow the client to do what is necessary independently. When these cases occur, the HTTP response always contains :
- HTTP status: an HTTP 403 or 404 status
- Code: a unique error code
Here are the different cases to manage :
Inaccessible feature: HTTP 404 – Error.Api.Usage.NoneMatching The customer does not have any subscriptions containing this feature. He must change his offer. Solution : Suggest that the customer change the offer.
No means of payment: Http 403 – Error.Customer.PaymentSettings.Missing The modification is subject to a fee, but the customer has no means of payment registered. Solution : show him the link to enter his means of payment.
Too many unpaid bills: Http 403 – Error.Customer.Billing.CappingReached The modification is paid for, but the customer has too many unpaid invoices (according to the thresholds defined in your parameters). Solution : The customer has to pay his old invoices.