Русский
Українська
Հայերեն
ქართული
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Article focus
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.
Mandatory website requirements for VPOS
Before production review, the site should already publish legal pages, prices, contacts and language versions.
A payment integration can be technically ready and still fail review if the website does not show the required merchant information and customer rules. Prepare these pages before test payment evidence and production access request.
If the product or service cannot be cancelled or refunded, state this clearly in the cancellation and refund policy. For Armenia, the Armenian website version is mandatory; when other languages exist, the same information should be present there as well.
- privacy policy;
- personal data processing policy;
- cancellation and refund policy, including non-refundable rules;
- Terms and Conditions: sale, delivery or service provision terms;
- prices for goods or services before payment;
- contact details: phone, e-mail, messengers or another working channel;
- Armenian website version and the same information in every available language.
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.
