Airwallex Payment Configuration Guide

Access the Dashboard

Airwallex provides both a Sandbox Environment  and a Production Environment . Log in to the corresponding dashboard first.

Create API Keys

In the dashboard, click Settings -> Developers -> API Keys to create a new API key.

Get API Key and Client ID

After creating the API key, the system automatically generates a Client ID. The API key is only visible upon creation. If you forget it, click Regenerate to create a new one.

Configure Legal Entity ID and Linked Payment Account ID

In the dashboard, click Settings -> Entities to create a new legal entity.

Create Webhooks

In the dashboard, click Settings -> Webhooks, then click New Webhook.

Configure Webhooks

For the API version, enter the fixed value 2025-11-11.

For the account, select the account corresponding to the Linked Payment Account ID in your payment configuration.

Check the following events:

• payment_intent.succeeded
• payment_intent.cancelled
• invoice.finalized
• subscription.in_trial
• subscription.active
• subscription.unpaid
• subscription.cancelled
• subscription.modified
• refund.accepted
• refund.failed

For the notification URL, enter the Webhook URL of the Airwallex Payment Processing actionflow in Momen. To get this URL: Click Action in the top navigation bar of the Momen editor, find the system-generated Airwallex Payment Processing actionflow in the left sidebar, click the trigger node at the top, and copy the Webhook URL from the right panel.

Click Create, and copy the Webhook Secret shown in the image below.

Enter Parameters into Momen’s Payment Configuration

Add One-Off Payment Action

In the click event of the payment button on the Momen frontend page, add the Airwallex Payment action and select One-Off Payment as the payment type.

Action Parameters:

Configure Airwallex Payment Processing Actionflow

When a user completes or cancels a One-Off Payment, the system-generated Airwallex Payment actionflow triggers automatically. Its processing logic is as follows:

1. Determine Payment Type: The Parse Event Type code block node parses the event type as payment_intent.succeeded (successful payment) or payment_intent.cancelled (cancelled payment), and enters the payment status change branch.
2. Sync Payment Status: The Sync Payment Status node automatically queries the payment record, updates its status to successful or cancelled, and records the alreadyProcessed indicator to prevent duplicate callback triggers caused by network retries. This node outputs 5 parameters:

3. Check if Payment Record Exists: Verify if the payment record is found by checking if the Payment ID is empty. If empty, it means the record was not found, and generally no action is taken; if not empty, proceed to the next branch.
4. Determine Payment Status: Confirm the final payment status by checking the payment status and the alreadyProcessed value.
   • If the payment status is SUCCESSFUL and alreadyProcessed is false, the payment is successful, and it enters the “Success” branch.
   • Otherwise, the payment failed or was cancelled, and it enters the “Other” branch.
5. Configure Custom Business Logic: Configure the business logic after a successful payment in the Success branch, such as changing the order status to paid using the Update Record action.

Add Refund Action

On the Momen page, add the Airwallex Payment action. Select Refund as the payment type.

Action Parameters:

Configure Callback Processing for Refund Success and Failure

When a refund succeeds or fails, the Airwallex Payment actionflow triggers automatically. Its processing logic is as follows:

1. Determine Refund Type: The Parse Event Type code block node parses the event type as refund.accepted or refund.failed, and enters the refund status change branch.
2. Sync Refund Status: The Sync Refund Status node automatically queries the refund record, updates its status to successful or failed, and records the alreadyProcessed indicator. This node outputs 6 parameters:

3. Check if Refund Record Exists: Verify if the refund record is found by checking if the Refund ID is empty. If empty, it means the record was not found, and generally no action is taken; if not empty, proceed to the next branch.
4. Determine Refund Status: Confirm the final refund status by checking the status and the alreadyProcessed value.
   • If the status is REFUNDED and alreadyProcessed is false, the refund is successful, and it enters the Success branch.
   • If the status is FAILED and alreadyProcessed is false, the refund failed, and it enters the Failure branch.
   • Otherwise, it indicates other situations, and generally no action is taken.
5. Configure Custom Business Logic: Configure the business logic after a successful or failed refund in the Success and Failure branches, such as updating the order status to refunded.

Create Products and Prices in the Airwallex Dashboard

Before initiating a recurring payment, you must configure the corresponding products and pricing plans in Airwallex.

1. Log in to the Airwallex dashboard, and click Billing -> Products in the left menu.
2. Click Create Product, and fill in the product name and description.
3. In the Pricing module of the product, click Add Price.
4. Select Recurring for the billing model, and set the amount and billing cycle (e.g., monthly, annually).
5. After saving, copy the generated price ID from the price list. You will need this ID when initiating a subscription in Momen.

Add Recurring Payment Action

On the Momen page, add the Airwallex Payment action. Select Recurring Payment as the payment type.

Action Parameters:

Execution Mechanism:

• When executing the action, the system prepares the subscription data on the backend and pops up the checkout for the user to authorize card binding and recurring deductions.
• Successful or failed authorization will trigger the corresponding branch on the frontend, but the actual activation confirmation of the subscription must be handled via the backend Webhook.

Handle Recurring Payment Status Changes

When a user’s recurring payment undergoes status changes such as trial, active, unpaid, renewed, or cancelled, the Airwallex Payment actionflow triggers automatically. Its processing logic is as follows:

1. Determine Subscription Status: The Parse Event Type code block node parses the event type as one of the following: subscription.in_trial (trial period), subscription.active (active), subscription.unpaid (unpaid), subscription.cancelled (cancelled), or subscription.modified (modified), and enters the subscription status change branch.
2. Sync Subscription Status: The Sync Subscription Status node, which is the first node in the branch, automatically queries the subscription record and updates its status to trial period, active, unpaid, cancelled, or modified. This node outputs 2 parameters:

3. Check if Subscription Record Exists: Verify if the subscription record is found by checking if the recurring payment ID is empty. If empty, it means the record was not found, and generally no action is taken; if not empty, proceed to the next branch.
4. Determine Subscription Status: Confirm the final subscription status by checking the value of status.
   • If status is ACTIVE, it indicates active, and enters the Active branch.
   • If status is CANCELLED, it indicates cancelled, and enters the Cancelled branch.
   • Otherwise, it indicates other situations, and generally no action is taken. If developers need to handle other statuses, they can add corresponding branches themselves.

Handle Recurring Payment Deductions

When an automatic renewal notification is received, the Airwallex Payment actionflow triggers automatically. Its processing logic is as follows:

1. Determine if it is a Recurring Payment: If the event type is invoice.finalized, it indicates a recurring payment, and enters the subscription renewal branch.
2. Parse Invoice id: The Parse Invoice id node automatically parses the Invoice ID.
3. Process Subscription Renewal: The Process Subscription Renewal node calls the Airwallex Subscription Renewal actionflow and passes the parsed Invoice id as an input parameter.

Processing logic of the Airwallex Subscription Renewal Processing actionflow:

1. Determine if it is an Automatic Renewal: Confirm if it is an automatic renewal by checking if the actionflow input parameter Invoice id is empty. If not empty, enter the Invoice id Not Empty branch.
2. Get or Create Renewal Payment Record: The built-in Custom Code node automatically generates or retrieves the Payment ID for the current renewal payment record based on the Invoice ID, and simultaneously returns the recurring payment ID corresponding to the subscription and the first order ID of the first associated order.
3. Check if Subscription Record Exists: Confirm that the renewal has a valid subscription record by checking if the recurring payment ID is not empty, and enter the Found Subscription Record branch.
4. Get Payment Record: Use the Get Single Record node to query the detailed data of the current renewal payment record using the Payment ID output in the previous step.
5. Check if Order ID Exists: Determine if the payment record is already associated with an order (i.e., the Order ID is empty). If empty, it means a new corresponding order has not yet been generated, and it enters the Create Order and Associate Payment branch; otherwise, it enters the Already Associated, Skip branch to avoid creating duplicate orders.
6. Get First Order: The system uses the previously obtained first order ID to query the original order data created when the user first subscribed.
7. Create Order (Requires Manual Configuration): Find the Create Record node used to create the order in the system-generated template. Developers must manually configure field assignments to assign the business data queried in the Get First Order node to the new order. For example, bind the order amount of the new order to Get First Order.Order Amount, and bind the user ID to Get First Order.User ID.
8. Update Order ID in Payment Record: The built-in Custom Code node automatically updates the newly created Order ID to the payment record of the current renewal, thereby completing the binding of the new order and the current renewal deduction.