Payment Overview

Momen’s payment feature connects to two payment gateways, Stripe and Airwallex, and covers the most common needs: one-time payments, recurring payments, and refunds. Momen takes care of the tedious parts, such as integrating with the gateway, confirming payment results, and recording transactions. You only need to complete a few steps, such as entering your merchant credentials, to start accepting payments.

Payments are available only to projects on the Pro plan. If a project is downgraded, payments stop working in production.

Payment gateways

A project can use several gateways at the same time, and can connect more than one merchant account to the same gateway.

Gateway	Clients	One-time payment	Recurring payment	Refund
Stripe	Web app	Yes	Yes	Yes
Airwallex	Web app	Yes	Yes	Yes

Payment features

One-time payment: The user pays once for an order, for example to buy a product, a course, or a membership.
Recurring payment: The user is charged automatically every billing period, which suits memberships, plan renewals, and other ongoing charges.
Refund: Refund all or part of a paid order.

When a payment completes, a refund succeeds, or a recurring payment changes status, Momen updates the payment records and runs the Actionflow you specify, so that you can update the order, grant access, or handle any other follow-up work.

Setup steps

Every gateway is set up with the following steps:

Bind an order table

Momen requires every payment and refund to belong to an order record, so you must bind an order table when you activate payments.

You create the order table yourself. Momen does not require any particular fields, but we recommend at least an amount, an order status, and a relation to the account table.

Open Action → Payment and select Create new. The first time a project uses payments, the Bind order table dialog opens first. Select your order table there. The account table cannot be used as the order table.

⚠️

Once the order table is bound, you can only replace it by disabling all payments and activating them again.

Binding the order table creates three system tables and relates them to it. You cannot change the structure or the data of these tables.

System table	Purpose
`payment_record`	Stores one-time payments and every subscription charge, and relates them to orders
`recurring_payment`	Stores subscriptions, their status, and the current billing period
`refund`	Stores refunds and relates them to payment records

See Payment Reference for the fields and status values of each table.

Create a payment configuration

In New payment, enter:

Config: A name for the configuration. It must be unique within the project.
Payment channel: The gateway. You cannot change it after the configuration is created.

Select Create and start configuration to open the configuration panel, which has three tabs: Configuration, Client management, and Permission management.

Enter merchant information

Under Configuration → Merchant information, enter the merchant information for the gateway.

Sensitive values, such as the Stripe secret key, can only be bound to a secret; you cannot enter them as plain text. Select the field to open the binding menu, then choose an existing secret or select New secret to enter a name and a value. You can manage secrets later under Settings → Secret.

Choose payment products

Under Payment products, select the checkout methods this configuration offers. Each product lists the clients it supports. A payment action can only use a product that is both available on the current client and enabled in the configuration.

Choose clients

Under Client management, select the clients that can use this configuration, or select All.

Set up payment result handling

Under Configuration → Payment result handling, bind an Actionflow to each payment event. See Handle payment results below.

Set permissions

Under Permission management, select which payment types each role can start through this configuration. A new configuration grants every role One-time payment and Subscription by default. Refund is not granted by default.

You can also review and change the permissions of all payment configurations under Settings → Permissions → Payment.

Publish

Changes to payment configurations, credentials, payment result handling, and permissions take effect in production only after you publish.

Start a payment

Add a Payment action to a page or component Trigger, then set the following:

Setting	Description
Payment type	One-Off Payment, Recurring Payment, or Refund
Payment configuration	The payment configuration to use. Configurations that are unavailable on the current client or do not support the selected payment type cannot be selected
Payment product	A payment product that is available on the current client and enabled in the configuration. If only one product qualifies, it is selected automatically

Once you select a configuration, the action shows the inputs for that gateway, such as the order ID, the amount, and the product name. See each gateway guide for its inputs and amount units.

Frontend result and final payment status

Payment actions have On success and On failure branches, which handle the result of the frontend request or the checkout interaction. For security reasons, actions that modify data cannot be added under On success of a payment action.

Whether an order has actually been paid is determined by the gateway notification. Do not ship goods, grant access, or mark an order as paid based only on the frontend On success branch.

Handle payment results

After a user pays, receives a refund, or is charged for a subscription renewal, the gateway notifies Momen. Momen verifies the notification signature, updates the status in the system tables, and then runs the Actionflow you bound to that event type.

Payment events

Event	When it runs	Gateways
On payment	A payment record changes to `SUCCESSFUL`	All
On refund	A refund record changes to `REFUNDED` or `FAILED`	All
On subscription status change	The status of a subscription changes	Stripe, Airwallex
On recurring billing	A subscription issues a new invoice and Momen creates a payment record for it	Stripe, Airwallex

No event runs when a payment is canceled or fails. On refund runs for both successful and failed refunds, so the Actionflow must check the refund record’s status and handle each case.

Bind an Actionflow

Select or create an Actionflow

Under Payment result handling, each event has its own run actionflow row. Select an existing Actionflow, or select New actionflow to have Momen create an Actionflow named after the configuration and the event and open it. Clear the selection to unbind the Actionflow.

Each event can be bound to at most one Actionflow.

Configure Actionflow inputs

Add an input to the Actionflow, such as an integer payment ID. Then return to Payment result handling, select the settings button next to the bound Actionflow to open its input configuration, and bind the input to data under Payment callback.

We recommend passing in only the ID of the record the event refers to, and then querying the full record inside the Actionflow. Under Payment callback, you can select the fields of the payment, refund, and recurring payment records, but not their related data. See Payment callback data for the data available to each event.

How events run

Momen updates the system tables before it runs your Actionflow, so any payment, refund, or subscription record you query in the Actionflow already reflects the latest status.
An event runs only when a status actually changes. If the gateway sends the same notification more than once, the Actionflow does not run again.
The Actionflow runs as an administrator and is not restricted by the current user’s data permissions.
Momen responds to the gateway before it runs the Actionflow. If the Actionflow fails, it is not retried; check the run logs to investigate. Steps that ship goods, grant access, or deduct inventory should still use order status checks or unique constraints to stay idempotent.

Handle subscription renewals

On recurring billing creates the business order for a new billing period. Momen has already created a payment record for that period, but the record is not yet linked to an order. The bound Actionflow must:

Use synchronous execution.
Output a single integer: the ID of the new order.

Momen writes this order ID back to the payment record for the period. When that charge succeeds, On payment runs with the order attached. If the Actionflow does not meet these two requirements, the editor reports an error. If it returns no order ID, the payment record for that period is not linked to any order.

Validate order amounts

Payment amounts come from the inputs of the frontend action. Before you ship goods or grant access, query the order in the On payment Actionflow and compare the order amount and currency with Order paid amount, the total of all successful payment records for that order.

Query payment results

The frontend can query the order table and, subject to data permissions, the payment_record, recurring_payment, and refund system tables. When you bind the order table, Momen grants the logged-in user role read access to these three tables. To keep the status up to date, use a real-time data source or query the page data again.

Delete a payment configuration

Select delete on a payment configuration card. Confirming also deletes the configuration’s payment result handling bindings and permission settings, and cannot be undone. Payment actions that use the configuration must then be given another payment configuration.

Disable all payments

The payment page provides Disable all payments. Confirming performs the following irreversible operations:

Deletes all payment configurations and their payment result handling bindings.
Deletes the payment_record, recurring_payment, and refund system tables and their relations. After you publish, their production data is deleted as well.

⚠️

To enable payments again, you must bind an order table again. Momen creates a new set of system tables and cannot restore or automatically reconnect the previous data. Make sure your historical data has been handled before you proceed.