Русский
Українська
Հայերեն
ქართული
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Article focus
Starting point: do not lose the lead context after payment
A service starts with a Tilda form, while payment and later work must remain tied to one CRM deal.
In a typical service scenario, a manager receives a Tilda lead, agrees the service and sends a prepayment link. When the link is created manually without a CRM id, the connection between payment, service and owner is lost.
In this case, CRM creates the payment request with deal id, service, amount, currency and expiry. The customer receives a link only after these details are fixed, so the payment does not become an anonymous bank-statement amount.
- Store CRM deal id in payment metadata.
- Do not change the amount after link creation without a new request version.
- Set expiry and a clear payment purpose.
- Keep personal data in the payment record to a necessary minimum.
Implementation: CRM moves only after a verified event
The deal does not depend on a screenshot or success page click; backend verification changes it after payment.
A webhook or server-side status check arrives at the backend, which validates identifiers, amount, currency and signature. Only then does the CRM deal move to a verified-prepayment stage.
Repeated events are safely ignored at the business-action layer. On failure or link expiry, the lead stays in an understandable stage and a manager can send a new link without losing history.
- Do not grant service access from a frontend signal.
- Make the webhook transition idempotent.
- Store confirmation time and external payment id in CRM.
- Handle expired, failed, pending and paid separately.
After launch: service delivery and refunds
A verified payment needs a delivery rule, notification and a transparent refund path.
After verification, the flow can create a task, grant access, confirm a booking or notify the customer. The concrete action needs an explicit business rule rather than a manager interpretation.
If a service is cancelled, refund is recorded as a separate event with a reason and a link to the original deal. This retains a clear history for support, accounting and the customer.
- Record the service delivery rule after paid.
- Do not mix prepayment, additional payment and refund in one CRM field.
- Store source, date and owner for a manual adjustment.
- Review expired links and pending payments in reconciliation.
FAQ
Can Tilda send a payment link without CRM?
It is technically possible, but a controlled process creates the link from CRM or backend and ties it to a lead, service and responsible employee.
When should a deal move to paid?
Only after server-side verification or a correctly processed webhook. A success page and screenshot do not prove a final result.
How should a service cancellation be recorded?
Record cancellation and refund as distinct events linked to the original deal and payment. The prepayment history must remain available.
