Getting started with OnPay
OnPay gained its own connection flow. Connect the account, review its requirements, and select OnPay on plans that should use it. Connecting does not automatically change existing plans. Run a synthetic checkout and keep card entry, authorization, capture, and decline as separate states. OnPay may capture automatically, so pre-authorization must fit the provider. See the current guide ### Check before use
Historical retrospective - August–December 2025 This article was written afterwards and describes the feature as it worked during the stated period.
OnPay gained its own connection flow. Connect the account, review its requirements, and select OnPay on plans that should use it. Connecting does not automatically change existing plans. Run a synthetic checkout and keep card entry, authorization, capture, and decline as separate states. OnPay may capture automatically, so pre-authorization must fit the provider. See the current guide (Markdown file, AI agent-friendly)
Check before use
Confirm that OnPay is ready, that the plan uses the expected provider, and that checkout shows the expected method. After a decline, follow payment status and do not register a manual payment until you know whether money was actually received.
Plan and checkout
After connecting, open each relevant plan and confirm that OnPay is selected as its active provider. Check currency and payment method in checkout, and run a test purchase with synthetic details. A customer may see a different flow when plan price or currency does not fit the provider.
Declines and cards
After a decline, read the displayed reason and follow the next action. A saved card can exist without a completed charge. When pre-authorization is used, check capture status separately.
Who sees which status?
The team sees gateway and Alunta payment status, while the customer sees checkout steps. They can be out of sync while the provider is confirming the result. Use “paid” only when the invoice shows the completed payment. A saved card can be used later but is not proof of payment.
If a plan cannot use OnPay, check price, currency, and active gateway. If card replacement only saves a card, it still needs to be attached to the relevant subscription.
FAQ and boundaries
OnPay is selected on plans, not only in the integration overview. An account can be connected while a plan still uses another provider. When a customer sees an authorization, the team must follow capture status. If card replacement saves a card but does not attach it to a subscription, repeat the specific subscription action.
Support scenario
Check an OnPay test purchase in checkout and invoice payment status. When the gateway captures automatically, do not tell the customer an authorization alone completed. With several plans, check the provider on the plan the customer actually buys.
Check after the action
Use this check during follow-up: note what was visible before the action, perform only the selected action, and check the document or mandate afterwards. Read a status again before informing the customer if it changes later. The retrospective describes the documented milestone; the current guide and interface determine today’s steps. Examples use fictional customers, amounts, and dates.
If the result differs
If the result does not match expectations, keep the visible status and investigate the relevant prerequisite instead of repeating the action blindly. Check currency, date, customer, payment method, and whether the document was already sent or booked. When answering a customer, distinguish what the system recorded from what the bank or recipient has not yet confirmed.
Close the workflow
A safe workflow ends with a new check, not with clicking Save or Send. Open the new invoice, mandate, or payment record and confirm that the result matches the message the customer receives. If confirmation is still missing, describe the status as pending and set the next review point.
The people and AI helpers behind the updates
Bo Møller and Emil Højbjerg are the primary developers behind Alunta. They spend most of their time coding, so they have delegated the wording of these explanations to our AI helpers.
The AI helpers write from the updates we have deployed to the product. Bo and Emil are behind the changes and remain responsible for ensuring the information reflects what was actually released.
