Alabajnaid/initial_user_stories

[alabajnaid]

PR: Initial User stories

[alabajnaid]

US foundations, needs a bit of work still planning to consider channel management as well (i.e. customers via their carrier can cancel recurring payments)

[PedroDiez]

@alabajnaid think we can move forward with the first User Story as it is the one that was seen ok in the previous meeting.

Could you please update PR only with the first one for review?

[alabajnaid]

HI @PedroDiez , Done

[PedroDiez]

Thanks @alabajnaid

[PedroDiez]

Hi @alabajnaid @AAlmohaimeed16

Commenting here. Please see below, adding some details on User Story indicated and also adding new one about retrieving payment/s details, think it can be added in the PR.

`User Story: Make a Payment

Item	Details
Summary	As an application developer belonging to an enterprise, I want to request (using my application server/backend service) a purchase (one-time -in initial phase- or recurring -in a latter phase- ) to be billed against a customer's carrier bill, so that I can offer customers payment alternatives.
Roles, Actors and Scope	Roles: Customer:User Actors: Application service providers, hyperscalers, application developers. Scope: Request Payment/Check out on Carrier Bill - Initiate Carrier Billing approval process with Customer from Carrier Channels (SMS/App)
Pre-conditions	The preconditions are listed below: The Customer:User has Carrier Billing activated. The Customer:User have initiated payment via Carrier Billing/Checkout from application/portal/product channel The PaymentRequester have verified that associated carrier service belongs to the Customer:User (Generally as part of adding a new payment method, 2FA or equivelant)
Activities/Steps	Starts when: The customer application server makes a request to the Carrier Billing Checkout to trigger the payment. Payment can be performed in 1-step or 2-step approach Ends when: The payment is completed and the customer application customer can query details of that payment
Post-conditions	After customer application server performs the payment, payment details can be queried
Exceptions	Several exceptions might occur during the Carrier Billing API operations - Unauthorized: Not valid credentials (e.g. use of already expired access token). - Invalid input: Not valid input data to invoke operation (e.g. merchant information not provided or unknown). - Permission Denied: Payment Amount and/or Accumulated Monthly Payments Amount overpass PSD2 regulation - Conflict: Internal configuration policies don't allow for Payment Execution/Cancellation.

User Story: Retrieve Payment/s details

Item	Details
Summary	As an application developer belonging to an enterprise, I want to get details of performed purchases/payments, individually or list of them (using my application server/backend service), by means of that application.
Roles, Actors and Scope	Roles: Customer:User Actors: Application service providers, hyperscalers, application developers. Scope: Request Payments Details done against Carrier Billing
Pre-conditions	The preconditions are listed below: The Customer:User has performed payments via application, both success and failed
Activities/Steps	Starts when: The customer application server makes a request to the Carrier Billing Checkout to get payment/payments details performed via that application Ends when: Response is received from Carrier Billing Checkout showing the details
Post-conditions	N/A
Exceptions	N/A	`

[alabajnaid]

Hi @PedroDiez , Noted, I will ammend it soon,

One point though, regarding exceptions, in Permission Denied, I think it's better to phrase it as denied by the carrier, without any mention of regulations, given that different regulations are eligible for each country, Having it "denied by carrier" as well captures other rejection reasons like the customer doesn't have Carrier billing activated and so on,

What do you think? @bigludo7 @SylMOREL

[PedroDiez]

@alabajnaid ok, in User Story is fine to be agnostic enough to have room for any situation. I used "Permission Denied" to be closer to exception type (technical view). Nonetheless, understand your point and it is fine.

[alabajnaid]

Updated PR

[PedroDiez]

Ok, no problem on update:

• Permission Denied: Payment Amount and/or Accumulated Monthly Payments Amount overpass PSD2 regulation

To something like (some wording below, up to your consideration, the wording you consider is suitable)

• Denied by Carrier: Any user/business condition and/or regulation that forbids the perform of the payment

[alabajnaid]

Yours is better, Will make a commit soon

[alabajnaid]

PR Updated, Missed commenting, 🙏

[PedroDiez]

See it OK

[PedroDiez]

Hi,

Regarding separating retrieve details of one payment from retrieving a list, it makes sense. Regarding search criteria it would be things that come discuss later.

Regarding 1-step and 2-step, although different from business perspecive, we would like to work in an approch where methods can work in both modes, aiming at simplifying API design. No matter from User story perspective in have separate entries.

[PedroDiez]

We agree on merge this PR and @bigludo7 will make another contribution to separate at User Case Level:

• 1-STEP and 2-STEP procedure
• Details of a Payment and List Of Payments based on some criteria