Frontend must not be the source of truth
Client-side code can show a success message, but it must not make the final order decision.
The main security rule for payments is simple: frontend does not confirm payment. It may send the customer to checkout and display the result, but backend makes the final decision after status verification.
If an order becomes paid only because the browser says so, a client-side error or manipulation can create false statuses. Critical changes must go through server-side verification.
- Do not trust success redirect without verification.
- Check amount, currency and order id on backend.
- Store the external payment id.
- Change business status only after a trusted event.
Webhook endpoints must be protected
A webhook accepts external events, so it should never behave like an unverified public form.
Webhook authenticity should be verified using the mechanism supported by the provider: signature, secret, trusted channel or an additional server-side status check.
The endpoint must also be idempotent. Repeated delivery of one event must not create a new order, a second receipt or duplicate CRM delivery.
- Verify signature or provider-specific trust mechanism.
- Protect against replay and duplicate events.
- Return a fast technical response to the provider.
- Use a queue for heavy downstream integrations.
Access rights and keys matter from day one
Integration keys, raw payloads and manual fixes need clear ownership and audit.
Even a payment MVP needs clear access to settings and logs. Who can see raw provider responses, retry event delivery or manually correct a status?
If these roles are not defined, support and engineering teams tend to use shared keys and manual fixes without a trace. That is risky for payments and customer trust.
- Least privilege for each role.
- Mask sensitive values in logs.
- Define owner and lifetime for integration keys.
- Audit manual changes and retry actions.
FAQ
Is HTTPS enough for secure online payments?
No. HTTPS is required, but backend verification, protected webhooks, idempotency, audit logs and access control are also needed.
Can card data be stored in CRM?
In general, websites and CRMs should not store full card data. Such data should be handled by the payment provider side.
What should be checked before launch?
Check server-side status verification, webhook security, retries, idempotency, logs, access rights and error scenarios.
