Checkout API: Use Case, Context and BaseLine Proposal

[PedroDiez]

Use Case: Goals and business opportunities:

The main goal is to increase customers’ engagement and ultimately user satisfaction by making it easy to pay for any digital asset (a.k.a. digital_good) via Carrier Billing Capabilites of an OB (Operator). For instance, the purchase of any digital asset while "playing" in streaming (e.g. Fornite) Our customers can enjoy flexibility and security by enabling as payment method the carrier billing.

What:

With Checkout API customers can easily pay with Operator monthly bill any digital purchase in just one-click:

• Charges a digital content purchase or subscription to the Operator customer bill (subscription desired in mid-term)
• Accessible in all devices (mobile (post-paid and pre-paid) and fixed (convergent or broadband)
• Protect customer ID from third parties and reinforces the security by applying a 2FA such as SMS/PIN code to authenticate the customer (desired feature in mid-term)

Concepts

• Purchase: The action of acquiring a good, service or product.
• Payment: The act or process of paying for that good, service or product.
• Carrier Billing: It means that the operator will perform the billing, accordingly to the user's configuration in the OB; usually this implies that the purchase will be included in the user invoice and then charged to the user, but actually other options may eventually happen, like charge against user prepay balance or other. Notice that this option do not explicitly define the underlying mechanism used by the specific OB, but means that the carrier (OB) will be doing the charge based on user configuration in their systems.

BaseLine Flow

API Baseline

Draft proposal to initiate track. In this PR: https://github.com/camaraproject/CarrierBillingCheckOut/pull/4

[bigludo7]

Hello @PedroDiez Is your API proposal coming from an API from standardization organization? In Orange we're using Payment API complying with the OMA (Open Mobile Alliance) REST Payment standard for Carrier Billing. We're also familiar with the TMF API for the pruchase (ordering) part. It did not seems to me that your proposal use any of this standard - correct ?

[alabajnaid]

Hi @PedroDiez, What do you have in mind when it comes to:

• Customer Identitifaction while privacy is still maintained (Aliases/Customer Reference Number comes to mind as a replacement for phone numbers/msisdn).
• In case of Verification, are abstracting Carrier Verification through the first call? i.e. once a payment is initialized, each operator verifies in their way then respond within a certain SLA

Also, the team suggested to add a refund api call coming from the API client, let us know what do you think.

When it comes to cancellation, should we consider PoNR (Point of No-Return)?

[PedroDiez]

Hello @bigludo7

Get your point. API proposal is a simplification of underlying functionality that can be provided (by interacting with underlying) OMA or TMF Forum approaches. Specifically OMA Interface covers a huge "spectrum" of Use cases.

What we have learned along last years is to have simpler APIs that covers specific USeCases needs and when new Use cases arrives evolve API specification even generating a new version in case it is needed

[PedroDiez]

Hello @alabajnaid

• Regarding Customer Identification, will be inherited internally from Access Token (auto-contained jwt), so every Operator can internally identify the customer behind after authorization perfomed.
• About Verification maybe not getting your point. Initial idea is to have a 2FA SMS/OTP scheme (not defined in API yet, I would try to add today, just to illustrate), so after preparePayment is triggered, Carrier can generate an SMS towards phone_number to have that 2FA verification

About refund feature is not included in first proposal as not needed by Use Case commented. I undersatnd your comment, it may be considered for a second phase, what do you think about it?

Yes, cancellation should we consider PoNR (Point of No-Return), when a purchase process is cancelled, new one has to be triggered. That one is discarded.

[bigludo7]

Thanks @PedroDiez for your answer.

So if I follow you, your contribution is based on Telefonica experience and not a standard.

From Orange perspective, we’re using Open Mobile Alliance 'based' API in lot of BUs, so we will prefer to have a Carrier Billing API as close as it is possible to a standard and not create a new one.

This should be a good topic for discussion in our forthcoming call ;) and we're open for contributing.

[PedroDiez]

Thanks @bigludo7 for the feedback.

Yes, this contribution is based to address use case commented, the design has differences with some standard approaches (like OMA or TMF, i agree on that), although provide a way to provide same/part of funcionality (Comparing to OMA Payment, part of that functionality), and aiming to be simpler for developers.

Understanding you point, from our perspective what we it would not be a good approach is to take exactly "as-is" a whole standard. Just because in CAMARA there are some guidelines and considerations to have in mind and also because it would provide benefit to end developers API covers the Use cases wanted to be addressed initially.

I really think it would be a good exercise to have some initial aligment in "features" needed for Use Cases and after that go deeper into the design of the API

[bigludo7]

Thanks @PedroDiez I tend to think we're on same page on the approach and looking on your answer we have probably same 'golden rules':

1. Get a Use-Case approach that allow us to define a MVP
2. Keep it simple (just good enough is fine)
3. Consistency between Camara API (critical for developer )

I will just add a fourth 'golden rule' - when 1 is defined, look for standard when exist (to not create an new one) with 2&3 in mind.

Happy to discuss this.

[PedroDiez]

Set this to close. It was aimed to open discussion in the WG