From 499b76408a7da7f88dc503aa05bc0f5276aa0d6d Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Wed, 4 Sep 2024 11:57:47 +0200 Subject: [PATCH] update_user_stories_file_name_per_RM_review --- ...Story.md => carrier-billing-User-Story.md} | 104 +++++++++--------- ...d => carrier-billing-refund-User-Story.md} | 0 2 files changed, 52 insertions(+), 52 deletions(-) rename documentation/API_documentation/{Carrier Billing User Story.md => carrier-billing-User-Story.md} (99%) rename documentation/API_documentation/{Carrier Billing Refund User Story.md => carrier-billing-refund-User-Story.md} (100%) diff --git a/documentation/API_documentation/Carrier Billing User Story.md b/documentation/API_documentation/carrier-billing-User-Story.md similarity index 99% rename from documentation/API_documentation/Carrier Billing User Story.md rename to documentation/API_documentation/carrier-billing-User-Story.md index 826e298..b32f4d7 100644 --- a/documentation/API_documentation/Carrier Billing User Story.md +++ b/documentation/API_documentation/carrier-billing-User-Story.md @@ -1,52 +1,52 @@ -**User Story: Make a Payment request in one step** -
- -| **Item** | **Details** | -| ---- | ------- | -| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service) a payment (one-time fee -in initial phase- or recurring -in a later 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 on Carrier Bill* \- Initiate Carrier Billing approval process with Customer from Carrier Channels (SMS/App) | -| ***Pre-conditions*** |The preconditions are listed below:
  1. The Customer:User has Carrier Billing activated as payment method.
  2. The Customer:User has initiated payment via Carrier Billing from application/portal/product channel
  3. The PaymentRequester has verified that associated carrier billing service belongs to the Customer:User (Generally as part of adding a new payment method, 2-Factor-Authorization or equivalent)
| -| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to trigger the payment.
**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:
| - - -**User Story: Make a Payment request in two steps** -
- -| **Item** | **Details** | -| ---- | ------- | -| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service) a payment (one-time fee -in initial phase- or recurring -in a later phase- ) to be billed against a customer's carrier bill, so that I can offer customers payment alternatives. The payment process will be split in 2 parts:
  1. Payment preparation request (that did not trigger the payment but only prepare it)
  2. Payment confirmation or cancellation. The payment confirmation triggers the payment itself. Optionally, as per business needs, payment confirmation may require a payment validation in advance (i.e. an optional step between payment preparation and payment confirmation)
| -| ***Roles, Actors and Scope*** | **Roles:** Customer:User
**Actors:** Application service providers, hyperscalers, application developers.
**Scope:** *Request Payment on Carrier Bill* \- Initiate Carrier Billing 2-steps approval process with Customer from Carrier Channels (SMS/App) | -| ***Pre-conditions*** |The preconditions are listed below:
  1. The Customer:User has Carrier Billing activated as payment method.
  2. The Customer:User has initiated 2-steps payment via Carrier Billing from application/portal/product channel
  3. The PaymentRequester has verified that associated carrier service belongs to the Customer:User (Generally as part of adding a new payment method, 2FA or equivalent)
| -| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to trigger a 2-steps payment.
**Intermediate steps:** The customer application server makes a request to confirm or cancel the payment preparation
**Ends when:** If payment confirmation is provided the payment is completed. If a payment cancellation is provided (explicit cancellation) or if neither a confirmation or cancellation is received after a predefined business delay (implicitly by expiration), the payment preparation is cancelled.
For both cases the customer application can retrieve and/or query details of that payment
| -| ***Post-conditions*** | After customer application server performs the payment, payment details can be queried. A payment can stay in preparation status only for a predefined business delay. | -| ***Exceptions*** | Several exceptions might occur during the Carrier Billing API operations:
| - - -**User Story: Retrieve a Payment from its identifier** -
- -| **Item** | **Details** | -| ---- | ------- | -| ***Summary*** | As an application developer belonging to an enterprise, I want to get details of one performed payment (from its id) 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:
  1. The Customer:User has performed payments via application, both success and failed
  2. The Customer:User has payment identification.
| -| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to get payments details performed via that application providing payment identifier.
**Ends when:** Response is received from Carrier Billing service showing the payment details | -| ***Post-conditions*** | Requester receives a complete representation of the payment. | -| ***Exceptions*** | Several exceptions might occur during the Carrier Billing API operations:
| - - -**User Story: Retrieve a Payment list** -
- -| **Item** | **Details** | -| ---- | ------- | -| ***Summary*** | As an application developer belonging to an enterprise, I want to get a list of performed payments from criteria (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 list done against Carrier Billing* | -| ***Pre-conditions*** |The preconditions are listed below:
  1. The Customer:User has performed payments via application, both success and failed
  2. The requester provides a list of criteria(s) to select payment (Customer/user identifier, payment status)
| -| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to get payment/payments details performed via that application
**Ends when:** Response is received from Carrier Billing service showing the details | -| ***Post-conditions*** | N/A | -| ***Exceptions*** | Several exceptions might occur during the Carrier Billing API operations:
| - -
+**User Story: Make a Payment request in one step** +
+ +| **Item** | **Details** | +| ---- | ------- | +| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service) a payment (one-time fee -in initial phase- or recurring -in a later 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 on Carrier Bill* \- Initiate Carrier Billing approval process with Customer from Carrier Channels (SMS/App) | +| ***Pre-conditions*** |The preconditions are listed below:
  1. The Customer:User has Carrier Billing activated as payment method.
  2. The Customer:User has initiated payment via Carrier Billing from application/portal/product channel
  3. The PaymentRequester has verified that associated carrier billing service belongs to the Customer:User (Generally as part of adding a new payment method, 2-Factor-Authorization or equivalent)
| +| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to trigger the payment.
**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:
| + + +**User Story: Make a Payment request in two steps** +
+ +| **Item** | **Details** | +| ---- | ------- | +| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service) a payment (one-time fee -in initial phase- or recurring -in a later phase- ) to be billed against a customer's carrier bill, so that I can offer customers payment alternatives. The payment process will be split in 2 parts:
  1. Payment preparation request (that did not trigger the payment but only prepare it)
  2. Payment confirmation or cancellation. The payment confirmation triggers the payment itself. Optionally, as per business needs, payment confirmation may require a payment validation in advance (i.e. an optional step between payment preparation and payment confirmation)
| +| ***Roles, Actors and Scope*** | **Roles:** Customer:User
**Actors:** Application service providers, hyperscalers, application developers.
**Scope:** *Request Payment on Carrier Bill* \- Initiate Carrier Billing 2-steps approval process with Customer from Carrier Channels (SMS/App) | +| ***Pre-conditions*** |The preconditions are listed below:
  1. The Customer:User has Carrier Billing activated as payment method.
  2. The Customer:User has initiated 2-steps payment via Carrier Billing from application/portal/product channel
  3. The PaymentRequester has verified that associated carrier service belongs to the Customer:User (Generally as part of adding a new payment method, 2FA or equivalent)
| +| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to trigger a 2-steps payment.
**Intermediate steps:** The customer application server makes a request to confirm or cancel the payment preparation
**Ends when:** If payment confirmation is provided the payment is completed. If a payment cancellation is provided (explicit cancellation) or if neither a confirmation or cancellation is received after a predefined business delay (implicitly by expiration), the payment preparation is cancelled.
For both cases the customer application can retrieve and/or query details of that payment
| +| ***Post-conditions*** | After customer application server performs the payment, payment details can be queried. A payment can stay in preparation status only for a predefined business delay. | +| ***Exceptions*** | Several exceptions might occur during the Carrier Billing API operations:
| + + +**User Story: Retrieve a Payment from its identifier** +
+ +| **Item** | **Details** | +| ---- | ------- | +| ***Summary*** | As an application developer belonging to an enterprise, I want to get details of one performed payment (from its id) 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:
  1. The Customer:User has performed payments via application, both success and failed
  2. The Customer:User has payment identification.
| +| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to get payments details performed via that application providing payment identifier.
**Ends when:** Response is received from Carrier Billing service showing the payment details | +| ***Post-conditions*** | Requester receives a complete representation of the payment. | +| ***Exceptions*** | Several exceptions might occur during the Carrier Billing API operations:
| + + +**User Story: Retrieve a Payment list** +
+ +| **Item** | **Details** | +| ---- | ------- | +| ***Summary*** | As an application developer belonging to an enterprise, I want to get a list of performed payments from criteria (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 list done against Carrier Billing* | +| ***Pre-conditions*** |The preconditions are listed below:
  1. The Customer:User has performed payments via application, both success and failed
  2. The requester provides a list of criteria(s) to select payment (Customer/user identifier, payment status)
| +| ***Activities/Steps*** | **Starts when:** The customer application server makes a request to the Carrier Billing service (API) to get payment/payments details performed via that application
**Ends when:** Response is received from Carrier Billing service showing the details | +| ***Post-conditions*** | N/A | +| ***Exceptions*** | Several exceptions might occur during the Carrier Billing API operations:
| + +
diff --git a/documentation/API_documentation/Carrier Billing Refund User Story.md b/documentation/API_documentation/carrier-billing-refund-User-Story.md similarity index 100% rename from documentation/API_documentation/Carrier Billing Refund User Story.md rename to documentation/API_documentation/carrier-billing-refund-User-Story.md