How to integrate CRM, website forms and payments without losing data

Connecting a form to a CRM looks like “when this happens, create that”. Production adds repeated submissions, incomplete fields, existing contacts, unavailable APIs, delayed payments and refunds. A dependable integration is not the arrow between three logos. It is the set of decisions that preserves data meaning when something fails.

The goal is not to synchronise everything with everything. It is to complete defined journeys—such as valid enquiry, sales opportunity and confirmed payment—with clear ownership, traceability and recovery. That prevents silent loss without turning a focused project into an unnecessary platform.

Define the journey before selecting connectors

Start with business events, not endpoints. A basic journey might be: a person submits a form; consent is validated; a contact is created or updated; an opportunity opens; a payment session is generated; the provider confirms payment; the CRM marks the opportunity won; confirmation is sent.

Include unhappy paths: duplicate contact, inconsistent amount, declined payment, refund and withdrawn consent. For every step, name the input, precondition, responsible system, result and failure action. This reveals whether process automation is enough or the integration needs durable state.

Do not automate ambiguity. If sales and finance disagree about when a customer becomes “active”, code merely makes that disagreement travel faster.

Decide which system owns each fact

The form captures intent; it should not become another customer database. The CRM normally owns the contact, marketing consent, account owner and sales stage. The payment provider owns authorisation, capture, refund and dispute. An application or ERP may own the order, invoice and fulfilment.

Create an ownership table:

Fact	Owner	Permitted copies
Name and sales channel	CRM	Application, for display
Original form message	Integration record	CRM when context helps
Financial status	Payment provider	CRM/ERP summary
Agreed amount and currency	Order or ERP	Provider and CRM
Consent and source	CRM or consent manager	Systems with a valid need

A copy is a projection, not a second authority. If a field can change in two places, define direction, precedence and conflict handling. Avoid generic two-way synchronisation: it is hard to reason about and easily creates loops.

Design an explicit data contract

Document names, types, required values and meaning. Normalise email, phone, country, currency and timezone, while retaining the original value when it helps investigation. Validate at the boundary: represent money as an integer minor unit or a decimal with an explicit rule, never an ambiguous floating-point value.

Separate business errors from technical failures. “Consent missing” or “currency unsupported” requires correction; a timeout or 503 may be retried. Do not send invalid fields into an endless queue.

Version the contract and test representative examples. Providers evolve: Stripe recommends checking the version and shape of webhook events, and every CRM has limits and conventions. Reading official documentation is part of design, not a final implementation chore.

Identity, deduplication and idempotency

Do not use a name as a key. Retain external identifiers for submission, CRM contact, opportunity, payment customer, session and transaction. Keep a mapping table when no system can store them all.

A user can click twice and a webhook can be delivered again. Idempotency ensures repeating the same intent has one effect. Generate a stable key when creating a payment and record an event ID before processing. Stripe documents idempotency keys for safely repeated requests; the same principle should cover CRM writes.

Deduplication and idempotency differ. Deduplication decides whether two contacts represent one person—a revisable business judgement. Idempotency prevents one technical operation from running twice. Combining them can merge customers incorrectly or duplicate legitimate opportunities.

Webhooks, polling and event order

Webhooks reduce latency but are not exactly-once calls. The endpoint should verify the signature, limit input size, record the event and respond promptly. Heavy work continues asynchronously. The OWASP API Security Top 10 provides a useful baseline for authentication, authorisation, resource consumption and validation risks.

Events may be repeated or arrive out of order. Do not assume “payment created” always precedes “payment confirmed”. Fetch current provider state when ordering matters, or enforce valid transitions: an old event must not move a refunded payment back to confirmed.

Scheduled polling still matters for reconciliation. A nightly job can compare provider payments with internal orders. It does not replace webhooks for fast feedback; it is a safety net for missed delivery or implementation defects.

Safe retries and an exception queue

Retry only temporary failures: timeouts, rate limits and 5xx responses. Use exponential delay with jitter and a maximum, and respect Retry-After. A 400 response will not improve through repetition; move it to review with enough context.

Every operation needs a status, attempt count, next execution, correlation ID, destination and sanitised error. A person should be able to inspect, correct and resume a case without asking a developer to edit the database.

Avoid distributed transactions across vendors. Persist local intent first and use an outbox or durable job. If the CRM fails after payment, the charge cannot be magically rolled back: record the discrepancy, retry the update and alert when it exceeds the expected window.

Security, privacy and payment scope

The browser must never receive CRM secrets or private keys. Verify webhook signatures using rotatable secrets; keep credentials in a secret manager with least privilege. Separate test and production environments and accounts.

Minimise data. Do not store full card numbers or CVC; use hosted pages or tokenised provider components to reduce PCI scope. The PCI Security Standards Council maintains the applicable standards. Encrypt sensitive data, limit logs and define retention and deletion.

Record consent basis and origin, but do not copy personal content into every log. An observable integration can use IDs and technical metadata without exposing the form message to every operator.

Observability and reconciliation

A useful dashboard answers: how many forms arrived, contacts and opportunities were created, payments remain pending, and errors need action? Use a shared correlation ID to trace a journey without searching by personal email.

Measure success rate, end-to-end latency, backlog age, retries and discrepancies. Alert on impact: ten understood cases in review may be less urgent than receiving no webhooks for an hour.

Reconciliation compares authoritative sources and raises exceptions; it does not overwrite blindly. Daily totals per currency, transaction counts and missing IDs reveal silent loss. That is the difference between “the connector is on” and “we know the business balances”.

A minimum architecture that works

For moderate volume, an API receiving forms and webhooks, a database for state and idempotency, and a delivery worker are often enough. Add a managed queue if it improves durability or absorbs bursts; do not introduce Kafka by reflex. Database, RabbitMQ or Kafka explains the trade-off.

The database stores submissions, external links, received events and outbound jobs. The worker claims work with locking, calls the destination and records the result. A small panel exposes exceptions and retry controls. This architecture is positively boring: testable, observable and operable without a platform team.

A CRM, forms, payments and ERP integration should deliver these mechanisms with the happy path, not merely connect credentials.

Rollout and testing plan

Implement one journey first: valid form, CRM contact and confirmation. Test in sandboxes, then add contract cases for duplicates, invalid signatures, timeout, rate limit, out-of-order event and refund. Simulate failure after making a payment but before saving the response.

Run a pilot with real users and value limits. Define daily reconciliation, an exception owner and a manual procedure. Enable gradually and retain a kill switch that stops new actions without dropping incoming events.

Before adding ERP, marketing or reporting, review the initial journey metrics. Every extra system multiplies states and permissions. Phased integration creates evidence and keeps responsibility clear when numbers do not match.

Frequently asked questions

Is a webhook better than scheduled polling?

Use webhooks for fast reaction and polling for reconciliation or providers without reliable events. Important payment flows commonly use both: webhooks operate and periodic queries verify.

Where should integration errors live?

In a persistent operational record with status, IDs, attempts and an actionable message. Technical logs support investigation but do not replace a queue that operations can review.

What if the CRM is down after payment?

Preserve payment as the authoritative fact, record the pending CRM update and retry idempotently. Alert if it exceeds the agreed window; never hide the discrepancy or charge again.

How do we prevent duplicate contacts?

Use an explicit policy: match known IDs first and normalised fields second, with review for ambiguous matches. Do not automatically merge people solely because they share an email address or phone.

Do we need an integration platform?

Not always. An iPaaS accelerates standard workflows; custom code suits specific state, rules or recovery. Evaluate limits, logs, per-operation cost and export before choosing.