Payment
Learn about Momen's built-in payment function. Build your native Stripe payment to boost your app's monetization.
Last updated
Learn about Momen's built-in payment function. Build your native Stripe payment to boost your app's monetization.
Last updated
In this doc, you'll learn about how to configure Stripe payment in your web app. Whether you're running an e-commerce platform, a subscription-based service, or even a SaaS product, providing users with a secure and easy-to-use payment system can significantly improve your service.
Sign up or log in to Stripe:
Payment features are only available in the Pro plan and above. If you downgrade, existing payment features will become inactive.
Before configuring payment, ensure you have an order table in your project. This table will be linked to the system's payment table.
Go to the Configuration settings and activate the Payment feature.
When activating, bind the order table you created before. The system will automatically create a one-to-many relationship between the order and payment tables. Please note:
All payment methods share the same order table.
Once bound, it cannot be unbound or replaced, and the order table cannot be deleted. Be cautious during the binding process.
Upon binding the order table and activating the payment feature, the system will automatically:
Create three tables in the data model (non-deletable, non-modifiable by the developer):
Payment Table: Stores payment records. The relationship is 1:N (one order can have multiple payments).
Recurring Payment Table: Stores recurring payment records.
Refund Table: Stores refund records. The relationship is 1:N (one payment can have multiple refunds).
Automatically generate two actionflows:
StripePaymentCallback: Triggered upon one-off payment completion.
StripeRefundCallback: Triggered upon refund completion.
StripeRecurringPaymentManagementCallback: Triggered upon initiating or canceling a recurring payment.
StripeRecurringPaymentDeductionCallback: For recurring payment deductions
Retrieve your Publishable Key and Secret Key from Stripe and fill them into the project configuration.
Find the Stripe actions in the Action List.
Single Payment Action
Refund Action
Payment ID (integer): Must be the ID from the payment table. Refund Amount (decimal): The amount to refund, which must be less than or equal to the original payment amount.
Recurring Payment Action
Before configuring, you must create a recurring payment price in Stripe and obtain the Price ID.
Type (option): Initiate for starting a recurring payment, Cancel for canceling it. Order ID (decimal): Must be the ID of the bound order table. Price ID (string): The price ID obtained from Stripe.
In the Permission System, you can set access controls for actions, especially for refund actions. It’s recommended to restrict this permission from regular users to avoid financial loss. A better approach is to create a special admin role with refund permissions.
Since front-end pages can be bypassed (e.g., users calling the success action via API without making a payment), it’s essential not to modify data in the "success" part of the payment action. The more secure method is to allow Stripe to notify your project’s backend, which will trigger corresponding Actionflows. These actionflows run securely in the backend.
This flow is triggered after payment completion. The built-in nodes include:
Callback Handler: This code block parses payment-related data and extracts key information (like order ID and payment status). It outputs:
orderId: The order ID provided during the payment action.
paymentStatus: The status of the payment.
callbackProcessed: Checks whether the callback is a duplicate, used along with paymentStatus to determine the real status of the payment.
Conditional Branch:
Based on the status of paymentStatus and callbackProcessed, determine whether the payment was successful
Configure your own business logic within the branch.
This flow is triggered after a refund is completed. The built-in nodes include:
Callback Handler: This block parses the refund data and extracts key information (like order ID and refund status). It outputs:
orderId: The related order table ID.
status: The refund status. If REFUNDED, it indicates a successful refund, otherwise, it indicates failure.
callbackProcessed: Checks whether the callback is a duplicate.
Conditional Branch: Handles post-refund logic (e.g., updating the order table), which you need to configure based on your business needs.
Triggered when recurring payments are created or canceled. In the code block, the data in the recurring_payment table will be updated.
When a recurring payment is created, Stripe will notify the project backend of any subsequent charges, triggering this actionflow. The code block will:
Retrieve charge information.
Create a new order.
Process the payment.
In the code block, modify the part that creates the order based on your specific order table. You can also adjust the amount for subsequent charges (which cannot exceed the amount set during the initial recurring payment).
Since updating the order/payment/recurring payment/refund tables occurs through custom actionflows and may take time, the front-end should use a subscription method to get the latest data. For example, after calling a payment action, the page can subscribe to the payment table to receive real-time updates on payment status.
Order ID (integer): Must be the ID of the bound order table. Currency (string): Stripe-supported currencies. See: Amount (decimal): Smallest currency unit. For example, to charge 100 USD, input 1000 (since USD’s smallest unit is cents). See:
