Payments Academy
MyCommerce project PAYMENT OPERATIONS STARTED LIVE 01 MyCommerce project - describes an e-commerce merchant that sells ACTIVE 02 Business requirements - Save start with the customer journey. QUEUED 03 Requirements sound simple - These requirements sound simple in a QUEUED 04 Business analyst - these rules explicitly QUEUED 05 Maximum payment retries - What is the maximum number of payment retries QUEUED 06 Finance - recurring revenue QUEUED The myCommerce project describes an e-commerce merchant that sells everyday products such as groceries, household goods, and personal care items. Step 1 of 6 MyCommerce project STARTED MyCommerce project describes an e-commerce merchant that sells ACTIVE Business requirements Save start with the customer journey. QUEUED Requirements sound simple These requirements sound simple in a QUEUED Business analyst these rules explicitly QUEUED Maximum payment retries What is the maximum number of payment QUEUED Finance recurring revenue QUEUED The myCommerce project describes an e-commerce merchant that sells everyday products such as groceries, household goods, and personal care items.
Business requirements for Subscribe n PAYMENT OPERATIONS IN PROGRESS LIVE 01 MyCommerce project - describes an e-commerce merchant that sells DONE 02 Business requirements - Save start with the customer journey. ACTIVE 03 Requirements sound simple - These requirements sound simple in a QUEUED 04 Business analyst - these rules explicitly QUEUED 05 Maximum payment retries - What is the maximum number of payment retries QUEUED 06 Finance - recurring revenue QUEUED The business requirements for Subscribe n Save start with the customer journey. Step 2 of 6 Business requirements for Subscribe n IN PROGRESS MyCommerce project describes an e-commerce merchant that sells DONE Business requirements Save start with the customer journey. ACTIVE Requirements sound simple These requirements sound simple in a QUEUED Business analyst these rules explicitly QUEUED Maximum payment retries What is the maximum number of payment QUEUED Finance recurring revenue QUEUED The business requirements for Subscribe n Save start with the customer journey.
Requirements sound simple PAYMENT OPERATIONS IN PROGRESS LIVE 01 MyCommerce project - describes an e-commerce merchant that sells DONE 02 Business requirements - Save start with the customer journey. DONE 03 Requirements sound simple - These requirements sound simple in a ACTIVE 04 Business analyst - these rules explicitly QUEUED 05 Maximum payment retries - What is the maximum number of payment retries QUEUED 06 Finance - recurring revenue QUEUED These requirements sound simple in a workshop, but each one hides several system decisions. Step 3 of 6 Requirements sound simple IN PROGRESS MyCommerce project describes an e-commerce merchant that sells DONE Business requirements Save start with the customer journey. DONE Requirements sound simple These requirements sound simple in a ACTIVE Business analyst these rules explicitly QUEUED Maximum payment retries What is the maximum number of payment QUEUED Finance recurring revenue QUEUED These requirements sound simple in a workshop, but each one hides several system decisions.
Business analyst must capture all PAYMENT OPERATIONS IN PROGRESS LIVE 01 MyCommerce project - describes an e-commerce merchant that sells DONE 02 Business requirements - Save start with the customer journey. DONE 03 Requirements sound simple - These requirements sound simple in a DONE 04 Business analyst - these rules explicitly ACTIVE 05 Maximum payment retries - What is the maximum number of payment retries QUEUED 06 Finance - recurring revenue QUEUED A business analyst must capture all of these rules explicitly, because developers cannot guess the retry timing or the notification wording. Step 4 of 6 Business analyst must capture all IN PROGRESS MyCommerce project describes an e-commerce merchant that sells DONE Business requirements Save start with the customer journey. DONE Requirements sound simple These requirements sound simple in a DONE Business analyst these rules explicitly ACTIVE Maximum payment retries What is the maximum number of payment QUEUED Finance recurring revenue QUEUED A business analyst must capture all of these rules explicitly, because developers cannot guess the retry timing or the notification wording.
Maximum payment retries PAYMENT OPERATIONS IN PROGRESS LIVE 01 MyCommerce project - describes an e-commerce merchant that sells DONE 02 Business requirements - Save start with the customer journey. DONE 03 Requirements sound simple - These requirements sound simple in a DONE 04 Business analyst - these rules explicitly DONE 05 Maximum payment retries - What is the maximum number of payment retries ACTIVE 06 Finance - recurring revenue QUEUED What is the maximum number of payment retries, and after how many failures is the subscription suspended. Step 5 of 6 Maximum payment retries IN PROGRESS MyCommerce project describes an e-commerce merchant that sells DONE Business requirements Save start with the customer journey. DONE Requirements sound simple These requirements sound simple in a DONE Business analyst these rules explicitly DONE Maximum payment retries What is the maximum number of payment ACTIVE Finance recurring revenue QUEUED What is the maximum number of payment retries, and after how many failures is the subscription suspended.
Finance needs reports on monthly PAYMENT OPERATIONS COMPLETE LIVE 01 MyCommerce project - describes an e-commerce merchant that sells DONE 02 Business requirements - Save start with the customer journey. DONE 03 Requirements sound simple - These requirements sound simple in a DONE 04 Business analyst - these rules explicitly DONE 05 Maximum payment retries - What is the maximum number of payment retries DONE 06 Finance - recurring revenue ACTIVE Finance needs reports on monthly recurring revenue, churn, and failed payment recovery. Step 6 of 6 Finance needs reports on monthly COMPLETE MyCommerce project describes an e-commerce merchant that sells DONE Business requirements Save start with the customer journey. DONE Requirements sound simple These requirements sound simple in a DONE Business analyst these rules explicitly DONE Maximum payment retries What is the maximum number of payment DONE Finance recurring revenue ACTIVE Finance needs reports on monthly recurring revenue, churn, and failed payment recovery.

Key points of this lesson, in order.

0:00 / 3:10 Step 1 of 6

Subscribe n Save: The myCommerce Project Scenario

Recurring Payments and 3RI, Lesson 3 of 7, Narration 3:10, D08 Cards and alternative payments

CaptureMandateRetry

What you will learn

Your objective. By the end of this lesson, you will be able to explain subscribe n save: the mycommerce project scenario. The myCommerce project describes an e-commerce merchant that sells everyday products such as groceries, household goods, and personal care items.

Why it matters. The project scenario is used in business analyst training because it forces the analyst to think about the full lifecycle of a subscription, not just the checkout page, and that lifecycle is where the real complexity lives.

Chapter objective: Learner designs recurring payments, including mandates, merchant-initiated transactions, and 3RI flows, and explains authentication, consent, and failure handling for repeat charges. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • MyCommerce project
  • Business requirements for Subscribe n
  • Requirements sound simple
  • Business analyst must capture all
  • Maximum payment retries
  • Finance needs reports on monthly

Key terms

Capture: The step in a card transaction where the merchant collects the authorised amount from the issuer, usually when goods are shipped.

Mandate: An authorisation given by a debtor to a creditor to collect payments from the debtor account by direct debit.

Retry: Repeating a failed request or message delivery after a delay, usually with a limit on attempts and a back off period.

Payment flow diagram showing Subscribe n Save: The myCommerce Project Scenario.

Practise this lesson

Exercise

Work out what the beneficiary receives for a $10,000 payment under OUR, SHA and BEN.

Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.

  1. What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.

Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.

Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.

Check your understanding

Practice question

A customer signs up for a subscription with a card, then replaces the card. The merchant wants the next charge to succeed without asking the customer to re-enter details. What mechanism supports this, and what consent is needed?

Takeaway and next step

What to remember

A BA who captures only the customer journey and ignores these needs has documented only half the system.

Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "3D Secure Requestor Initiated (3RI) Transactions".

Transcript and full text

Show transcript

The myCommerce project describes an e-commerce merchant that sells everyday products such as groceries, household goods, and personal care items. The merchant wants to launch a subscription service called Subscribe n Save, where a customer picks products, chooses a delivery frequency, and gets a discount of five to ten percent on every repeat order. The customer saves money, the merchant gets predictable repeat revenue, and both sides benefit. The project scenario is used in business analyst training because it forces the analyst to think about the full lifecycle of a subscription, not just the checkout page, and that lifecycle is where the real complexity lives. The business requirements for Subscribe n Save start with the customer journey. A customer must be able to select products, choose a delivery interval such as weekly or monthly, set a start date, and see the discounted price before confirming. The customer must be able to manage the subscription from an account page, including changing products, skipping a delivery, changing the delivery date, and cancelling at any time. The merchant must be able to charge the customer automatically on the schedule, send a reminder before each charge, and handle a failed payment without losing the customer. These requirements sound simple in a workshop, but each one hides several system decisions. The most important system requirement is that the subscription payment must be triggered by the system, not by the customer. This is what makes Subscribe n Save different from a normal online purchase. The merchant's billing engine must wake up on the scheduled date, check the subscription status, calculate the amount including any price changes, attempt the payment using the stored credential, and then trigger the order fulfilment process if the payment succeeds. If the payment fails, the system must follow a retry schedule and notify the customer. A business analyst must capture all of these rules explicitly, because developers cannot guess the retry timing or the notification wording. A good business analyst asks hard questions before documenting Subscribe n Save. What happens when the price of a product changes between orders, and does the customer need to approve the new price. What happens when a product goes out of stock on the delivery date, and is the order partially fulfilled or delayed. How many days before the charge does the customer get a reminder, and can they change the order after the reminder is sent. What is the maximum number of payment retries, and after how many failures is the subscription suspended. What does the customer see on the account page when a payment fails. Each answer becomes a requirement, and missing answers become defects in production. The myCommerce scenario also teaches the BA to think about the non-functional requirements that stakeholders often forget. The billing engine must process thousands of renewals every day, so performance and scheduling matter. The payment data must be stored securely, so tokenization and PCI DSS scope matter. The subscription data must be available to customer service, so the support team needs a screen that shows the mandate status, the payment history, and the next billing date. Finance needs reports on monthly recurring revenue, churn, and failed payment recovery. A BA who captures only the customer journey and ignores these needs has documented only half the system.

The myCommerce project describes an e-commerce merchant that sells everyday products such as groceries, household goods, and personal care items. The merchant wants to launch a subscription service called Subscribe n Save, where a customer picks products, chooses a delivery frequency, and gets a discount of five to ten percent on every repeat order. The customer saves money, the merchant gets predictable repeat revenue, and both sides benefit. The project scenario is used in business analyst training because it forces the analyst to think about the full lifecycle of a subscription, not just the checkout page, and that lifecycle is where the real complexity lives.

The business requirements for Subscribe n Save start with the customer journey. A customer must be able to select products, choose a delivery interval such as weekly or monthly, set a start date, and see the discounted price before confirming. The customer must be able to manage the subscription from an account page, including changing products, skipping a delivery, changing the delivery date, and cancelling at any time. The merchant must be able to charge the customer automatically on the schedule, send a reminder before each charge, and handle a failed payment without losing the customer. These requirements sound simple in a workshop, but each one hides several system decisions.

The most important system requirement is that the subscription payment must be triggered by the system, not by the customer. This is what makes Subscribe n Save different from a normal online purchase. The merchant's billing engine must wake up on the scheduled date, check the subscription status, calculate the amount including any price changes, attempt the payment using the stored credential, and then trigger the order fulfilment process if the payment succeeds. If the payment fails, the system must follow a retry schedule and notify the customer. A business analyst must capture all of these rules explicitly, because developers cannot guess the retry timing or the notification wording.

A good business analyst asks hard questions before documenting Subscribe n Save. What happens when the price of a product changes between orders, and does the customer need to approve the new price. What happens when a product goes out of stock on the delivery date, and is the order partially fulfilled or delayed. How many days before the charge does the customer get a reminder, and can they change the order after the reminder is sent. What is the maximum number of payment retries, and after how many failures is the subscription suspended. What does the customer see on the account page when a payment fails. Each answer becomes a requirement, and missing answers become defects in production.

The myCommerce scenario also teaches the BA to think about the non-functional requirements that stakeholders often forget. The billing engine must process thousands of renewals every day, so performance and scheduling matter. The payment data must be stored securely, so tokenization and PCI DSS scope matter. The subscription data must be available to customer service, so the support team needs a screen that shows the mandate status, the payment history, and the next billing date. Finance needs reports on monthly recurring revenue, churn, and failed payment recovery. A BA who captures only the customer journey and ignores these needs has documented only half the system.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.