OPEN QUESTIONS - Carrier Billing Checkout Proposal

[PedroDiez]

Issue to track questions & comments received regarding Carrier Billing Checkout Proposal

• [x] Q1-STC: Create a new purchase - no customer details like mobile number (MSISDN) (which is endUserId in Orange YAML) is seen in request payload.
• [x] Q2-STC: In create purchase request does the total_amount includes merchant fee?
• [x] Q3-STC: Prepare/cancel/confirm payment – no payload – can we move the path parameter to payload as it is a POST call
• [x] Q4-ERICSSON: Management of Purchase LifeCycle
• [x] Q5-ERICSSON: merchant.fee: Why this param is mandatory when a given contract indicating this is signed in advance. Already queried and waiting response on it.
• [x] Q6-STC: Concept of merchant.id why is mandatory, because it may be identified by API client credentials (Orange for instance do in that way). Comment is in line of making it optional so only provided when merchant is different from API requester. Telefonica checks this in order to see if can be settled to optional adding an exception in case for any case it is required.
• [x] Q7-order.id: optionality of order.id

[PedroDiez]

Q4-ERICSSON: Management of Purchase LifeCycle

There is more than one option to manage "Purchase" concept lifecycle:

• Settle "purchases" never attempted to be paid in a specific status, so it can be tracked (if history of attempted purchases would be required)
• Run Internal Periodic Process in Checkout Server (a.k.a. Cronjob) to clean "purchases" never attempted. This is the way/option currently implemented by Telefonica, as there is no a "strong" requirement to have history registry of purchases never attempted to be paid.

[PedroDiez]

About questions Q5 and Q6, we are thinking about them and provide feedback (initially it seems no problem in making it optional, we are doing an assesment)

[PedroDiez]

Q2-STC: In create purchase request does the total_amount includes merchant fee?

YES

[PedroDiez]

Q5-ERICSSON: merchant.fee && Q6-STC: Concept of merchant.id && Q7-order.id

• merchant info is optional, but if included: at least merchant.id is required merchant.fee is optional
• order.id is set to optional

Proposal updated accordingly in v0.6.0

[PedroDiez]

Update Q1 and Q3

Still under internal analysis

[PedroDiez]

Q1-STC: Create a new purchase - no customer details like mobile number (MSISDN)

phone number will be included in payment request for both one-step and two-step cases, being optional parameter.

There are cases where phone number can be inferred from authentication context, therefore contained within an opaque JWT-based Authorization Header:

• Mobile Connect based authentication
• Mobile IP based authentication.

On the other hand there are scenarios where phone number has to be explicitly indicated:

• User/Pwd based authentication
• Fixed IP based authentication

Considering this rationale, phone number will be included in payment request being optional parameter

[PedroDiez]

Q3-STC: Prepare/cancel/confirm payment – no payload – can we move the path parameter to payload as it is a POST call

POST call is not forbidden to have an empty body, indeed POST call can be mainly used to:

• To create a resource, then usually a representation of the resource is provided

• To perform an specific action over a resource. The resource is the "purchase" represented by purchase_id, then the reason to model it within the path URL

Therefore that is the reason, from design point of view to keep it as currently is. Anyway in Payment request (1-step and 2-step), now it is indicated phone number as input parameter

[PedroDiez]

Closed as PR https://github.com/camaraproject/CarrierBillingCheckOut/pull/64 is already triggered