Changelog

​

Expanded Payment Request webhook payloads

• mode — live or test, depending on the API key that created the Payment Request. Always present.
• statement_descriptor — the text shown on the customer’s statement, present when it was set on the Payment Request.

• payment_request.updated is sent when a Payment Request becomes expired or failed, as well as when you update it.
• A paid Payment Request sends both payment_request.updated and payment_request.paid.
• Deleting a Payment Request does not send an event.

• payment_page.payment_received is not available yet and has been removed until it is released.

​

Added Complete Payment Session endpoint and expanded Payment Method Options

• POST /collect/payment_sessions/{id}/complete — update an existing Payment Session with a new payment method selection. Used in merchant-controlled flows to reuse the session after a failed attempt without creating a new one. Accepts selected_payment_method and visible_payment_methods using the same identifier formats as session creation.

• mobile_money.phone_number — pre-fills the customer’s phone number for mobile money payment methods (for example M-Pesa, MTN MoMo, Airtel Money). Must be in E.164 format and match the session country.
• capitec_pay.phone_number — pre-fills the customer’s Capitec-registered phone number. Must be in E.164 format and match the session country.
• prefill_mode — controls how the checkout handles pre-filled payment method fields. review presents the value for the customer to confirm; auto_advance skips the review step and advances automatically.

• payment_method_selection — controls who manages payment method selection during checkout. gateway (default) has Moment Checkout display and manage selection. merchant delegates selection to the merchant’s own checkout; requires return_url and redirects back automatically after each payment attempt.

​

Renamed the instant_eft payment method type to pay_by_bank

• type: instant_eft is now type: pay_by_bank
• The instant_eft details object (containing bank) is now pay_by_bank

​

Consolidated in-flight Payment statuses under a single pending status

• pending: the payment has an in-flight attempt and is awaiting a final outcome

• 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.

​

Introduced payment_outcome on Payment Sessions, deprecating payment_status

• payment_outcome — the canonical state of the payment associated with the session

• 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

• payment_status is now deprecated. It continues to be populated with paid, unpaid, or pending for backwards compatibility. New integrations should read payment_outcome.

​

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

• POST /collect/payments/{id}/captures — capture a previously authorised payment
• POST /collect/payments/{id}/voids — cancel a previously authorised payment

• 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_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

​

Added Mandate and Subscription Options to Payment Sessions API

• 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 added to support plan-driven recurring payments
• Recurrence can be configured as daily, weekly, or monthly with flexible scheduling

​

Added Payment Rules and Schema Refinements to Billing API

• 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

• 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

​

Added Presentation Mode to Payment Sessions API

• 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

• 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

​

Introduced Payments API

• GET /collect/payments/{id} — retrieve the full Payment object by its identifier

​

Introduced Payment Requests API

• 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

• 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

​

Added obligation.amount_applied Webhook to Billing API

​

Introduced Payment Pages API

• 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

​

Introduced Billing API

• POST /billing/customers — create a customer
• GET /billing/customers/{customer} — retrieve a customer
• PATCH /billing/customers/{customer} — update a customer

• POST /billing/accounts — create an account under a customer
• GET /billing/accounts/{account} — retrieve an account
• PATCH /billing/accounts/{account} — update an account

• 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

​

Added Checkout Options to Payment Sessions API

​

Introduced Payment Sessions API

• POST /collect/payment_sessions — create a new payment session
• GET /collect/payment_sessions/{id} — retrieve a payment session by its identifier

• 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