One Step Payment - create Payment - clarification required.

[PedroDiez]

This discussion item compiles the information gathered within the issue One Step Payment - create Payment - clarification required, that has been lost from WG history.

GitHub support have allowed the WG to recover info. In this discussion item, the info is compiled, for tracking purposes
Issue was created by STC

cc @bigludo7, @rartych

[PedroDiez]

INPUT

Team ,
Can you please help me with inputs on below points related to API

1. Is it mandatory to implement the Asynchronous use case . if it is not mandatory then , can I remove Webhook parameters from – createPayment API (1 step payment)
2. In the createPayment API – what is the difference between clientCorrelator and merchantIdentifier , which field shall we use for client profileID mapping
3. In the schema – request field clientCorrelator is optional but in the description it is written as “This field SHOULD be present.” So I am confused if it is mandatory or non-mandatory .
4. What is the difference between paymentItem and chargingInformation object , as both has the same fields , also how to decide which one to use.
5. As per the given description – request field phoneNumber is optional and should be inferred from the token . So here , are you referring to JWT token ? Currently we are using Opaque tokens so can’t we make phone number field as mandatory ? or it mandatory to implement JWT token and infer phone number only from the token .
   We currently have OAuth 2.0 Implemented with Client Credential Flow . Here , we are not capturing user phone number in the token so please update if it is mandatory to implement it to get certified or I can continue with OAuth 2.0 based implementation.
6. What does validatePayment API do ? Is it mandatory to implement it for certification ?
7. Which field(s) to use for identifying individual merchant and service? merchantIdentified, serviceid, productid fields appear as optional in the specifications so which other mandatory fields can we rely on for this purpose?

[PedroDiez]

Commments:

Hi Team ,
Below I am sharing the points discussed and agreed in a meeting on 26th June . Please review acknowledge
• It was confirmed by CAMARA representative that, for the certification Validate API and Async flows of all the APIs are not mandatory as these are optional. Mandatory use cases are only one step payment, 2 step payment with reserve, commit and cancel along with inquiry API’s.
• As per UAE Tax law it is mandatory for operator to know type of VAT, but CAMARA API’s does not support VAT type (in case of no vat or with vat), API’s only have tax included or not included (as optional). Additionally, as per TDRA regulations for any app store partners, operator should have control on minimum and maximum amount that can be deducted. These regulatory compliances are not directly supported in the CAMARA API’s but as per yesterday’s discussion and agreement, operator can make use of any optional parameter to mark it as mandatory while implementing the specification and keep these business configurations and control inside operators’ business logic based on the mutual agreement with operator and partner.
• CAMARA API’s does not support REFUND which in our case is must . As per our yesterday’s forum discussion, CAMARA would release another version in near future which will have REFUND and other changes.
• As per CAMARA representative, it has been confirmed that for the certification, only mandatory API parameters are required, and depending on the business requirements, operator has full control to make any optional parameter as mandatory either in request or response, provided it is mutually agreed between partner and operator.
• Depending on the agreement and business case with partner, handling of error descriptions, status and codes can also be customized over and above provided standard errors, and this will not affect standardization.
• As per the discussions, operators are free to choose and make any one or more currencies as mandatory. For UAE, only AED is supported, and it is aligned to have only AED deductions with partners.
regards
Prashant Sidana

[PedroDiez]

RESPONSE:

As promised written responses:

1. Is it mandatory to implement the Asynchronous use case . if it is not mandatory then , can I remove Webhook parameters from – createPayment API (1 step payment)
   Carrier Billing Payment is designed in both sync and async modes in order for a Telco Operator to accomodate its implementation to the model taht is suitable according to its internal systems and potential country regulation. Therefore it is NOT a MUST to implement both modes
2. In the createPayment API – what is the difference between clientCorrelator and merchantIdentifier , which field shall we use for client profileID mapping
   clientCorrelator is targeted to perform idempotency, in the case an API request does not receive response and it was finally able to be manged by the Telco Operator
   merchantIdentifier is a business information, to identify the final merchant, specially issued for the scenarios where intermediates are in the E2E flow -i.e. aggregators-. In any case it is up to the Telco Operator to agree in a given integration to request the Merchant/Aggregator to provide that information, based on their working
3. In the schema – request field clientCorrelator is optional but in the description it is written as “This field SHOULD be present.” So I am confused if it is mandatory or non-mandatory .
   It is not mandatory, but recommened its support. Probably some integrations/contract would required it based on the agreements between the Telco Operator and the merchant/aggregator
4. What is the difference between paymentItem and chargingInformation object , as both has the same fields , also how to decide which one to use.
   chargingInformation provides the information about the whole payment. paymentItem is targeted where there is a payment involving different concepts and based on integration agreement it is requested to the Merchant/Aggregator to use this model. At the end it depends on the commercial model agreed in the integration
5. As per the given description – request field phoneNumber is optional and should be inferred from the token . So here , are you referring to JWT token ? Currently we are using Opaque tokens so can’t we make phone number field as mandatory ? or it mandatory to implement JWT token and infer phone number only from the token .
   We currently have OAuth 2.0 Implemented with Client Credential Flow . Here , we are not capturing user phone number in the token so please update if it is mandatory to implement it to get certified or I can continue with OAuth 2.0 based implementation.
   phoneNumber is not mandatory as in 3-legged Authorization (Access Token), Telco Operator can infer the phoneNumber based on Access Token info (internal process up to the Telco Operator); any case it could be provided by API client and Telco Operator would match the phoneNumber against Access Token info (403 - Phone Number provided not matching Access Token context ("code": "CARRIER_BILLING.INVALID_TOKEN_CONTEXT","message": "Phone Number does not match with Access Token context").
   At least, cases we have talked for Payment usually involves user identificatuon, by means of network-based auth, so 3-legged token is generated. In the context you commented, the identification of the final user is delegated to the merchant/aggregator so as the API requester is considered trusted for the Telco Operator and their can invoke by means a 2-legged token.
   I do not have a strong opinion on that due to it is not a business case we have so far, trying to provide a "making-sense response I would say":

• If the Telco Operator considers the scenario as Trusted it would be up to the Telco Operator scope to expose this AuthZ mode. In this case, it is clear phoneNumber is needed to be provided.
• If the regulation of the privacy in the country allows for the scenario it "should" not be a problem (that is a personal view only)
• "Red line" would be if there is a need of the final customer to provide consent for the Payment and that consent needs to be stored and managed by the Telco Operator, in such a case 3-legged is required
  cc @bigludo7, @rartych just in case this scenario would happen in any commercial market you would be aware, just to provide a more suitable feedback

1. What does validatePayment API do ? Is it mandatory to implement it for certification ?
   validatePayment is only valid for 2-STEP Payment Case and it is optional to expose just in case when making preparePayment, a validation is required (validationInfo object, action=validate, authorizationId returned.). Our proposal for this endpoint when not applicable and invoke by a client is: HTTP 400 - CARRIER_BILLING.INVALID_AUTHORIZATION_ID
2. Which field(s) to use for identifying individual merchant and service? merchantIdentified, serviceid, productid fields appear as optional in the specifications so which other mandatory fields can we rely on for this purpose?
   They are optional parameters, up to the Telco Operator to implement them based on Business Scenarios or applicable regulations. This is the reason to keep them optional