Skip to main content
​
NewChangedDeprecated

​
Consolidated in-flight Payment statuses under a single pending status

The Payment status field now reports a single pending value for any payment with an in-flight attempt, instead of exposing the more granular initiating, pending_action, and processing values at the payment level. The detailed phase of an in-flight payment is an attempt-level concern and is no longer surfaced on the payment aggregate status.New value on Payment status:
  • pending: the payment has an in-flight attempt and is awaiting a final outcome
Deprecations:
  • initiating, pending_action, and processing are deprecated as Payment status values. They remain valid enum members for backwards compatibility, but new payment responses and webhook payloads will not emit them. Integrations should treat any of these legacy values as pending.
What this means for webhooks:Payments that previously appeared with status: initiating, processing, or pending_action will now appear with status: pending. Terminal statuses (succeeded, failed, cancelled, expired) and draft are unchanged. If your integration matches on the legacy in-flight values, map them to pending.👉 See the Payment object reference
​
NewChangedDeprecated

​
Introduced payment_outcome on Payment Sessions, deprecating payment_status

The Payment Session resource now exposes a richer payment_outcome field that supersedes payment_status. The new field carries the existing paid, unpaid, and pending values and adds three more to cover flows that the binary payment_status could not express cleanly.New field on the Payment Session object:
  • payment_outcome — the canonical state of the payment associated with the session
Values:
  • not_started — payment has not been initiated
  • pending — payment is in flight, awaiting a final outcome
  • paid — payment succeeded (terminal)
  • unpaid — payment failed, expired, or was cancelled (terminal)
  • reserved — funds were authorised on a capture_method: manual flow; subsequent capture and void operations are tracked on the underlying Payment resource
  • payment_method_verified — supported amount: 0 verification flow succeeded and the payment method was vaulted
Deprecations:
  • payment_status is now deprecated. It continues to be populated with paid, unpaid, or pending for backwards compatibility. New integrations should read payment_outcome.
👉 See Payment Session Lifecycle
​
New

​
Added Authorisation and Capture and Payment Method Verification to Payments and Payment Sessions APIs

Introduced support for authorisation and capture payment flows, and payment method verification, across both the Payments and Payment Sessions APIs.Payments API — new endpoints:
  • POST /collect/payments/{id}/captures — capture a previously authorised payment
  • POST /collect/payments/{id}/voids — cancel a previously authorised payment
Payments API — new fields on the Payment object:
  • capture_method — whether the payment uses immediate or manual capture
  • authorized_amount — the amount held under authorisation
  • paid_amount — the amount captured and collected
  • voided_amount — the amount voided when an authorisation is cancelled
  • intent — indicates whether the payment was initiated for verification or payment collection
  • metadata now accepted on capture and void requests
  • external_reference enforces a pattern of ^[a-zA-Z0-9_-]+$
Payment Sessions API:
  • payment_method_options added to One Time, First In Series, and Next In Series payment sessions to configure the capture method and enable payment method verification flows
👉 See Payments Overview👉 See Authorisation and Capture👉 See Payment Method Verification
​
New

​
Added Mandate and Subscription Options to Payment Sessions API

Payment sessions now support mandate and subscription options for recurring payment flows. Merchants can configure consent terms, validity periods, execution schedules, and payment amount controls when initiating a mandate.Mandate options:
  • mandate_options added to First In Series payment sessions
  • Supported mandate types: Scheduled, On Demand, and Installment
  • Execution constraints control when recurring payments can be collected: day_of_month, day_of_week, day_of_year, nth_day_of_month
  • Period limits define how much can be collected within a given window, with support for calendar-aligned and cycle-aligned windows
  • Amount can be fixed or variable within defined bounds
Subscription options:
  • subscription_options added to support plan-driven recurring payments
  • Recurrence can be configured as daily, weekly, or monthly with flexible scheduling
👉 See Mandate Options👉 See Subscription Options
​
NewChanged

​
Added Payment Rules and Schema Refinements to Billing API

New fields on the Account object:
  • payment_rules.min_amount — minimum payment amount accepted
  • payment_rules.max_amount — maximum payment amount accepted
  • payment_rules.overpayment_allowed — whether payments exceeding the balance are accepted
  • payment_rules.underpayment_allowed — whether partial payments are accepted
Additional changes:
  • external_reference on accounts now excludes the reserved bacc_ prefix
  • external_reference on customers and bills now excludes the reserved bcus_ prefix
  • conflict and payment_not_found error codes added across all billing endpoints
👉 See Account Object
​
NewChanged

​
Added Presentation Mode to Payment Sessions API

presentation_mode is now available on checkout_options in the Payment Sessions API to control how the Moment checkout is presented to customers.Supported modes:
  • redirect — redirects the customer to the Moment-hosted checkout page
  • embedded_modal — displays checkout as a modal overlay within the merchant’s page
  • embedded_inline — renders checkout inline within the merchant’s page
Additional changes:
  • display_pay_button replaces the previous displayPayButton field on embedded mode options
  • payment_not_found added as a new error code across create and retrieve endpoints
👉 See Presentation Mode
​
New

​
Introduced Payments API

Initial release of the Payments API.Endpoints:
  • GET /collect/payments/{id} — retrieve the full Payment object by its identifier
The Payment object includes the payment status, amount, currency, country, mode, payment method details, external reference, last payment error, metadata, and timestamps.Notable: payment_method_details is returned as a discriminated union — each payment method type (Card, Capitec Pay, Instant EFT, Zapper, MTN MoMo) is a distinct subschema identified by a type discriminator.👉 See Payment Object👉 See Payments Overview
​
New

​
Introduced Payment Requests API

Initial release of the Payment Requests API, enabling merchants to create and share direct payment links with customers via SMS, email, or messaging apps.Endpoints:
  • POST /collect/payment_requests — create a payment request
  • GET /collect/payment_requests/{id} — retrieve a payment request
  • PATCH /collect/payment_requests/{id} — update a payment request
  • DELETE /collect/payment_requests/{id} — delete a payment request
Webhooks:
  • payment_request.created — triggered when a payment request is created
  • payment_request.updated — triggered when a payment request is updated
  • payment_request.paid — triggered when a payment request is paid
👉 See Payment Requests Overview
​
New

​
Added obligation.amount_applied Webhook to Billing API

The obligation.amount_applied webhook event is now available, triggered when an amount is received against a billing obligation such as a bill, account, or customer.👉 See obligation.amount_applied
​
New

​
Introduced Payment Pages API

Initial release of the Payment Pages API, enabling merchants to create branded hosted payment pages that customers can access via a shareable link.Endpoints:
  • POST /collect/payment_pages — create a payment page
  • GET /collect/payment_pages/{id} — retrieve a payment page
  • PATCH /collect/payment_pages/{id} — update a payment page
  • DELETE /collect/payment_pages/{id} — delete a payment page
  • PATCH /collect/payment_pages/{id}/inactive — deactivate a payment page
  • GET /collect/payment_pages/{id}/transactions — retrieve transactions for a payment page
Webhooks:
  • payment_page.payment_received — triggered when a payment is received on a hosted page
👉 See Payment Pages Overview
​
New

​
Introduced Billing API

Initial release of the Billing API, providing full lifecycle management of customers, accounts, and bills.Customers:
  • POST /billing/customers — create a customer
  • GET /billing/customers/{customer} — retrieve a customer
  • PATCH /billing/customers/{customer} — update a customer
Accounts:
  • POST /billing/accounts — create an account under a customer
  • GET /billing/accounts/{account} — retrieve an account
  • PATCH /billing/accounts/{account} — update an account
Bills:
  • POST /billing/bills — create a bill
  • GET /billing/bills/{bill} — retrieve a bill
  • PATCH /billing/bills/{bill} — update a bill
  • POST /billing/bills/{bill}/void — cancel a bill
👉 See Billing Overview
​
New

​
Added Checkout Options to Payment Sessions API

checkout_options added to One Time and First In Series payment sessions, allowing merchants to configure the checkout experience presented to customers.👉 See Checkout Options
​
New

​
Introduced Payment Sessions API

Initial release of the Payment Sessions API.Endpoints:
  • POST /collect/payment_sessions — create a new payment session
  • GET /collect/payment_sessions/{id} — retrieve a payment session by its identifier
Payment sessions support three flow types, each with its own configuration:
  • One Time — a single payment flow with checkout and payment method options
  • First In Series — initiates a recurring payment flow and captures the mandate
  • Next In Series — continues a recurring payment flow using an existing mandate
👉 See Payment Sessions Overview