Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Tilda checkout should hand the order to payment backend
A custom payment gateway is not just a bank redirect, but a contract between storefront, backend and payment provider.
In Tilda, the order is often created by the storefront while payment continues in an external flow. To avoid losing orders, define which fields go to payment backend: order id, amount, currency, items, contacts, return URL and request id.
Backend should create a payment session, store internal payment id and return a controlled payment redirect. After that, order state should not become final only because the buyer reached the success page.
- send a stable order id to backend;
- verify amount and currency before payment creation;
- store payment attempt before redirect;
- separate order status and payment status.
Signatures and validation protect order data
The payment endpoint should fail closed and accept only valid requests, without trusting arbitrary browser parameters.
If an endpoint accepts amount, currency and order without signature or merchant setting verification, an attacker can try to change parameters before payment creation. The request should be verified before provider call, and errors should be safe and not expose secrets.
Even with a valid signature, backend should validate required fields, currency format, amount, merchant id and request id reuse. A repeated request should not create several independent payments for one order.
- verify signature and merchant configuration;
- do not trust amount only from frontend;
- use idempotency for repeated requests;
- log invalid signature and validation errors.
How to return status to Tilda, CRM and accounting
The buyer needs a clear result, while operators need verified status, provider reference and exception list.
After payment, provider callback or server-side status check should update the internal payment and then deliver a normalized result to Tilda context, CRM, ERP or fiscal service. If integration stops at redirect, some successful payments can stay unresolved.
Support needs paid, pending, failed, expired, refunded and manual review. Reconciliation needs provider reference, order id, amount, currency, paidAt, fiscal status and delivery retry history.
- do not close the order without server-side verification;
- store fiscal status and payment status separately;
- create CRM tasks only for exceptions;
- include Tilda orders in daily reconciliation.
FAQ
Can a Tilda order be treated as paid after the success page?
No. Success page confirms the customer journey, but final status should be set after server-side payment verification or a trusted provider callback.
What if the buyer closes the payment page?
The order should stay in pending payment. Backend should wait for callback, run status verification or move the case to manual review.
Should Tilda orders be sent to CRM?
If managers process orders or services in CRM, send normalized payment status, provider reference and attempt history, not just a comment.
