One-time payment flow

When you render the hosted payment page for a one-time MoMo payment, Zuora displays a QR code that the customer uses to complete authorization.

If the asynchronous response from Adyen is successful, Zuora does the following:

1. Creates a payment with Payment status = Processed and Gateway State = Submitted, and creates a MoMo payment method record.

2. Displays a QR code so the customer can complete authorization within 10 minutes.

3. Listens for the callback result from Adyen and MoMo, then returns the result to the hosted payment page callback function.

4. Updates Gateway State based on the webhook result:

   • If AUTHORIZATION is true, Zuora sets Gateway State to Settled.

   • If AUTHORIZATION is false or OFFER_CLOSED is true, Zuora sets Gateway State to FailedToSettle.

   • If the transaction times out, Zuora displays the error callback result returned from Adyen on the hosted payment page.

If the asynchronous response from Adyen is failed, Zuora throws an error on the hosted payment page with the error message returned from Adyen.

Saved payment method and token values

After the payment method is created, you can retrieve it through the Zuora UI and API operations. In the Electronic Payment Methods section of the customer account page, Zuora stores token values used for recurring payments.

Use the following token mappings:

• Token ID = shopperReference.

• Second Token ID = recurringDetail.

• Third Token ID = merchantReference.

After a payment is processed, Zuora populates Reference ID with a UUID and maps it to pspReference by default. If you want Reference ID to be populated with the payment number mapped to Adyen merchantReference, submit a support ticket to Zuora Global Support.

Recurring payments flow

Recurring payments are processed with the stored tokens. For the end-customer experience in recurring payments, refer to Adyen's MoMo recurring-payments documentation.

Supported and unsupported features

Supported features include one-time payment processing, recurring payment processing, referenced refunds, standalone payment method validation, payment method creation without making a one-time payment, Real-Time Reconciliation, and idempotency support for retrying payment and refund transactions.

Unsupported features include payment cancel (void), non-referenced refunds, Delayed Capture, the Stored Credential Transactions framework and sharing NTI feature, creation of MoMo payment methods through the UI or API operation, and Batch Gateway Reconciliation.