Русский
Українська
Հայերեն
ქართული
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Article focus
Give payment status one source of truth
Conflicting status rules across a website, CRM and ERP create costly support work.
The browser should never be the final source of truth for an order. A backend service verifies the provider result and publishes a normalized payment event that CRM, ERP, fiscal and notification systems can consume consistently.
Decide in advance which system owns the commercial order and which system owns the technical payment attempt. This prevents CRM cards, ERP documents and storefront orders from overwriting one another after an asynchronous callback.
- Store order id and provider payment id together.
- Use explicit pending, paid, failed and refunded states.
- Update downstream systems after verification only.
Design for duplicate and late events
A reliable integration expects retries, repeated webhooks and out-of-order delivery.
Payment providers can retry delivery and a customer can repeat an action after a slow network response. The payment layer needs idempotency keys, unique constraints and state-transition rules so that repeated events do not duplicate invoices, receipts or shipments.
A late pending event must not downgrade a paid order. Preserve every event in an audit timeline, but allow only valid status transitions to change business data.
- Deduplicate by provider event or operation key.
- Validate amount, currency and order id.
- Log rejected and repeated transitions for support.
Send the fields operations actually need
CRM and ERP should receive a usable business event instead of an unfiltered provider payload.
The downstream contract should include stable identifiers, normalized status, confirmed amount and currency, provider reference, timestamps and an audit link. This lets support reconcile a customer request without access to sensitive card information.
Keep provider-specific raw payloads restricted to technical investigation. CRM users generally need a clear invoice state, payment history and a safe action for retrying a link or initiating a controlled refund.
- Separate technical payloads from business fields.
- Mask sensitive data in logs.
- Record manual corrections and retry actions.
FAQ
Should CRM receive provider webhooks directly?
Usually no. A backend payment service should verify and normalize the event before CRM or ERP receives it.
How should duplicate webhooks be handled?
Store a provider event identifier or idempotency key and return the previously processed result without duplicating business actions.
What should support be able to see?
A timeline of the order, payment attempt, verified status, downstream deliveries and any manual action.
