Skip to main content
There are multiple possible scenarios, each tailored to specific customer and merchant interactions. Below are some examples, grouped by one-time payments, recurring payments, and cross-cutting flows.

​
One-time Payments

  • Scenario: A one-time payment where the customer is present, and the payment method is not saved for future use.
  • Use Case: Customers making a one-time purchase without any desire to save their payment method for future use.
  • Session Type: one_time
  • Behavior:
    • The customer completes the payment via the hosted Checkout page.
    • The payment method is not saved because the save_payment_method option is set to never.
  • Example: Buying a product or service without storing the card for future payments.
  • Scenario: A one-time payment where the customer is present, and the payment method is only saved for future payments where the customer is present.
  • Use Case: Customers who want to reuse their payment method for other purchases initiated by them in the future.
  • Session Type: one_time
  • Behavior:
    • The customer completes the payment via the hosted Checkout page.
    • The payment method is saved for use when the customer is present and the save_payment_method option is set to always or prompt.
  • Example: Purchasing a product and saving the card for future use during checkout.
At a glance:

​
Recurring Payments

See Recurring Payments for how mandates, subscriptions, and payment methods work together.
  • Scenario: The first payment in a series where the customer is present, and the payment method is saved with a mandate for future payments.
  • Use Case: Merchants setting up recurring payments for subscriptions or installment plans.
  • Session Type: first_in_series
  • Behavior:
    • The customer completes the initial payment via the hosted Checkout page.
    • A mandate is created authorising future payments that occur when the customer is not present.
  • Example: Signing up for a monthly subscription with an initial payment.
  • Scenario: A follow-up payment where the customer is not present, using a payment method saved in a previous first_in_series session.
  • Use Case: A merchant initiates a recurring payment based on an existing mandate.
  • Session Type: next_in_series
  • Behavior:
    • No customer interaction is required.
    • The payment is processed programmatically using the saved payment method and existing mandate.
  • Example: Processing a subscription payment each month.
At a glance:

​
Cross-Cutting Flows

Authorisation and capture, payment method verification, and payment method selection aren’t tied to a specific session type; they layer on top of a one-time or recurring payment.
  • Scenario: A merchant wants to control which payment methods are available or preselected when the customer lands on Checkout.
  • Use Case: Merchants who present payment method options on their own page and want Moment Checkout to open with a specific method already selected.
  • Session Type: one_time or first_in_series (any session where the customer lands on a hosted Checkout page).
  • Behavior:
    • The merchant creates a session with visible_payment_methods: ["card"].
    • The customer lands on the Checkout page with the card form displayed directly, since only one payment method was specified.
    • If multiple values are passed in visible_payment_methods, the Checkout page displays all listed methods without preselecting any.
  • Example: A merchant’s product page shows a card icon; clicking it opens Checkout with the card form already active.
See the full Quickstart Guide for more details.
  • Scenario: A payment where funds are reserved at checkout but not settled until the merchant explicitly captures them.
  • Use Case: Merchants who need to verify stock, review for fraud, or wait for shipment before collecting funds.
  • Session Type: one_time
  • Behavior:
    • The merchant sets payment_method_options.card.capture_method: manual when creating the session.
    • The customer completes the payment flow as normal. On success, funds are authorised (held) but not settled.
    • The merchant then uses the Payments API to capture or void the authorisation.
  • Example: Authorising R1 500.00 at checkout, then capturing R1 000.00 when 2 of 3 items ship and voiding the remaining R500.00.
This option is card-specific. If the customer pays with a non-card method, the payment falls back to immediate settlement. See the full Authorisation & Capture guide for details.
  • Scenario: Verify a customer’s card without reserving any funds when setting up a mandate for future recurring payments.
  • Use Case: Subscription businesses that need to confirm a card is valid before initiating future charges (e.g., free trial sign-up).
  • Session Type: first_in_series
  • Behavior:
    • The merchant creates a first_in_series session with amount: 0.
    • The customer completes the checkout flow. The card is verified via payment method verification.
    • A mandate is created for future merchant-initiated payments without any initial charge.
  • Example: A subscription service verifying a customer’s card at sign-up before the first billing cycle begins.
See the full Authorisation & Capture guide for details.
  • Scenario: Verify and save a customer’s card without charging them, for future customer-initiated purchases.
  • Use Case: E-commerce platforms or marketplaces where customers save a card at account creation for faster future checkouts.
  • Session Type: one_time
  • Behavior:
    • The merchant creates a one_time session with amount: 0.
    • The customer completes the checkout flow. The card is verified and saved.
    • No mandate is created. The saved card is available for future customer-present payments.
  • Example: A customer adding a payment method to their account without making a purchase.
See the full Authorisation & Capture guide for details.
At a glance: