Orange contribution for Carrier Billing API

bigludo7 commented 1 year ago

Orange contribution for Carrier Billing API:

aligned with operations described in the UC sequence diagram
separate payment for purchase
use OMA asset to define the Payment resource

bigludo7 commented 1 year ago

Looking for feedback from @PedroDiez @alabajnaid @SylMOREL Thanks

PedroDiez commented 1 year ago

Thanks @bigludo7 will be taking a look to it

PedroDiez commented 1 year ago

Hi @bigludo7, all

Understood the contribution/proposal.

It is clear it is a different approach regarding Telefonica one and based on OMA Payment, something commented in initial discussion.

Just to provide some feedback in two points.

Reagrding why making a proposal based on purchase/payment from Telefonica side:

Purchase represents the "object" that is gonna be paid
Payment represents the act of paying that "object"

¿Why using a purchase?

Because it allows to "package" in advance what it is goign to be purchased and present to the user
Because it allows to decouple payment from "purchase contextualization" so different purchase concepts can be modelled without impacting/adapting input information in payment (OMA Payment you need to provide object details) and we consider that is simpler for API developer. So purchase can be evolved with heterogeneuos concepts/payables without impact in payment (no extra/optional input needed)
Because it also enable to have busness logic associtated to the concept itself (i.e. some concepts may be not allowed, or depending on user status). So it is something that can be decoupled from payment
Because in a (theoretical) context of managing different payment methods it could also provide information about which payment method used in advance

Regarding 1-STEP/2-STEP: (Orthogonal to above)

For a model where a 2FA SMS OTP validation is required (or other interactions) we see a 2-STEP model in order to provide a good/consistent UX.

User makes a prepare payment, details to trigger OTP validation are in response and, after that confirmPayment can be done (cancel is the other option).

For a model where it is not required additional interaction, 1-STEP also can fit with a good UX. Here what we see is try to simplify the model having dual "behaviour" in one endpoint.

One endpoint could be /payment: that can adquire dual "behaviour" and signal in response when 2-STEP (additional_action) is required. Other endpoints coud be /payment/confirm or /payment/cancel

Let's talk tomorrow anycase

bigludo7 commented 1 year ago

Thanks @PedroDiez for your review

Let's discuss this tomorrow - I summed-up below our position for each point.

Purchase/payment I think we agree to disagree on the Purchase/payment ;)

For us these entities are distinct business concepts and must be handle as such. Of course, and I agree with your point, a purchase may be paid and a payment is the way to make it.

We need this purchase entity for sure, and the there is is a link to payment, but not one a 'subresource' of the other.

We can have purchase (order) without payment (your model support this)
We can also have payment without purchase - I can pay a bill and here the reference should be the customer bill and not the purchase (your model does not support this UC )
We can have several payments for one purchase/order (one payment for item 1&3, another for item 2) and in this case you should be able to link purchase/order item to payment (your model does not support this UC).
We can have to manage refund (your model support this but only at one purchase level whih is a limitation)
We have distinct state engine at purchase/order (draft, validated, inProgress, delivered, etc..) than for payment (charged, reserved, cancelled, etc...)

So speaking of API path we could have: POST purchase (or POST productOrder as specified in TMF) POST Payment but for us not POST purchase/{purchaseId}/payment which seems to us not accommodating all UC and not reflecting business requirements (at least ours).

I took a look on TMF and also there is distinct API for productOrder to Payment.

Use of oma API For us, use an existing standard should be primarily assessed before to try something new in order to get traction and ease adoption. After if the standard doesn't fit or too complex let move from it. Regarding oma proposal, I guess we could work on the proposal to simplify it to remove useless attributes in our context and extend it to add a purchase (or productOrder)id attribute in the chargingMetaData.

One step/Two step payment From a business perspective this is very different process right ? This was the rational for 2 end-points. Isn't confusing with same endpoint ? the POST ....payment/confirm works in this case for both one step & two steps no ?

endUserId or any identifier to get the msisdn explicitly We cannot assume in all UC that the payment request will be triggered from the device. For us the API could be call from an app not running on the device but on back end. Of course in this case the SMS OTP validation is required but we should accommodate this UC and having the capability to pass a endUserId in the request. I guess same request from @alabajnaid if I understood.

Thanks

Ludovic

PedroDiez commented 1 year ago

Hi,

@bigludo7, after checking, we would not accept this proposal. I want to be transparent and look for guidance at this point.

bigludo7 commented 1 year ago

Thanks @PedroDiez for the answer.

Do you know if there is a governance process in case of disagreement? Thanks

PedroDiez commented 1 year ago

Hi,

@bigludo7, I have asked Markus.

Have commented some suggestions, although there is no formal procedure in CAMARA defined. We are checking.

Some are in the line of agreeing in an intermediate proposal, however proposals paradigm is different and (think) really difficult to do this.
Others are in line of making a vote

Best Regards Pedro

GarethWGSMA commented 1 year ago

Hi,

No I'm not aware of anything formal. The idea was to reach a consensus. But if there is simply no consensus to be had then we're in uncharted territory I think. Let me check with @Mark Cornall and see if there is anything in the Terms and Conditions.

Gareth

From: Ludovic Robert @.> Sent: 28 November 2022 13:10 To: camaraproject/CarrierBillingCheckOut @.> Cc: Subscribed @.***> Subject: Re: [camaraproject/CarrierBillingCheckOut] Orange contribution for Carrier Billing API (PR #16)

"This email has been received from an external source - please review before actioning, clicking on links, or opening attachments"

Thanks @PedroDiezhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPedroDiez&data=05%7C01%7Cgwilliams%40gsma.com%7C9e4fb9a791a54ed9959808dad141d89f%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C638052377985174091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5chB8szfep%2BmOfTzvAdsmjKYsI2OM%2Bt6%2BxJCTR8eJIQ%3D&reserved=0 for the answer.

Do you know if there is a governance process in case of disagreement? Thanks

- Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcamaraproject%2FCarrierBillingCheckOut%2Fpull%2F16%23issuecomment-1329065615&data=05%7C01%7Cgwilliams%40gsma.com%7C9e4fb9a791a54ed9959808dad141d89f%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C638052377985174091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jR3VX2k%2Fsi9UFtdQg02T%2FnyBPns3hvswH7VNUQHdUyA%3D&reserved=0, or unsubscribehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA2I7LGGFL4AMEVTVBNDN6HDWKSVKHANCNFSM6AAAAAASDOUFJA&data=05%7C01%7Cgwilliams%40gsma.com%7C9e4fb9a791a54ed9959808dad141d89f%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C638052377985174091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y1PXko6yhcnYg4swv83UD4SvifXK7lZd3BnR4gGs1Og%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.***>

.

GarethWGSMA commented 1 year ago

Within the Camara charter it says Technical decisions Technical decisions that only affect a single Sub Project are made informally by the maintainers of this Sub Project, and lazy consensushttps://couchdb.apache.org/bylaws.html#lazy is assumed. If no consensus can be reached, the matter may be resolved by majority vote. Technical decisions that span multiple parts of the CAMARA Project should be discussed and made on the CAMARA Project mailing list. Decisions are usually made by lazy consensushttps://couchdb.apache.org/bylaws.html#lazy. If no consensus can be reached, the matter may be resolved by majority vote.

Though I am sure I have seen a more formal process, possibly from Shilpa. Shilpa, Markus and Jose can probably advise better on the process. Happy to take any part to resolve. It is a topic that has come up very recently.

Mark

From: Gareth Williams @.> Date: Tuesday, 29 November 2022 at 13:46 To: camaraproject/CarrierBillingCheckOut @.> Cc: Mark Cornall @.***> Subject: RE: [camaraproject/CarrierBillingCheckOut] Orange contribution for Carrier Billing API (PR #16) Hi,

No I’m not aware of anything formal. The idea was to reach a consensus. But if there is simply no consensus to be had then we’re in uncharted territory I think. Let me check with @Mark Cornall and see if there is anything in the Terms and Conditions.

Gareth

From: Ludovic Robert @.> Sent: 28 November 2022 13:10 To: camaraproject/CarrierBillingCheckOut @.> Cc: Subscribed @.***> Subject: Re: [camaraproject/CarrierBillingCheckOut] Orange contribution for Carrier Billing API (PR #16)

“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”

Thanks @PedroDiezhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPedroDiez&data=05%7C01%7Cmcornall%40gsma.com%7C2c5f4b0f09c4412806f108dad2101497%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C638053263756624481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rSyi4RUC5PBht05SNPvt1i0aJx2gZUMb5ytsDWFeufE%3D&reserved=0 for the answer.

Do you know if there is a governance process in case of disagreement? Thanks

— Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcamaraproject%2FCarrierBillingCheckOut%2Fpull%2F16%23issuecomment-1329065615&data=05%7C01%7Cmcornall%40gsma.com%7C2c5f4b0f09c4412806f108dad2101497%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C638053263756624481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QMc6AeUf8wQGdKoeW6GsFP4w3lU%2BeJxB5su1%2FEsvl9c%3D&reserved=0, or unsubscribehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA2I7LGGFL4AMEVTVBNDN6HDWKSVKHANCNFSM6AAAAAASDOUFJA&data=05%7C01%7Cmcornall%40gsma.com%7C2c5f4b0f09c4412806f108dad2101497%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C638053263756624481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9KAAxn9mC%2Fi31YxLT1ju2NSiymYv1h8q%2FLfMjA3gGBk%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.***>

.

camaraproject / CarrierBillingCheckOut

Orange contribution for Carrier Billing API #16