Integrations with accounting, CRM and payment systems
The three integrations almost every business application needs, what each involves, and where they go wrong.
The short answer
Nearly every business application ends up connected to three kinds of system: accounting, where invoices and payments must land; a CRM, where customers and their history live; and a payment provider, where money moves. Each integration is a small project with the same skeleton: credentials, data mapping, triggers, error handling, logging, change management. Each also has its own trap. Accounting is about reconciliation, not the API. CRM is about deciding which system owns which field. Payments are about never building it yourself and designing for duplicates and failures. All three need idempotency, a person who receives the errors, and a plan for the day the vendor changes the API.
The three integrations
| Integration | What flows | The hard part | Typical failure |
|---|---|---|---|
| Accounting | Customers, invoices, credit notes, payments, sometimes products | Mapping to the chart of accounts and tax codes; reconciliation when amounts differ | Invoices posted twice after a retry; a refund never reaching the ledger |
| CRM | Contacts, companies, deals, activities, notes | One source of truth per field; matching duplicates; two-way sync conflicts | Two systems overwriting each other; a contact updated in one and stale in the other |
| Payments | Charges, refunds, payouts, disputes, subscription events | Verifying webhooks; handling every failure state; never touching card data | A charge succeeded but the order was not marked paid; a webhook processed twice |
Building them properly
- Decide the source of truth per kind of data, in writing, with the business.
- Map fields including formats, required values, tax codes and what happens when there is no match.
- Use hosted flows for payments: the provider’s checkout, their signed webhooks, their test mode.
- Make every write idempotent, keyed on your own identifiers, so retries never duplicate.
- Log every event with identifiers on both sides, so any record can be traced.
- Route errors to a person with enough context to fix them: which record, what failed, what to do.
- Test the unhappy paths in the vendors’ sandboxes: timeouts, rejections, partial failures, duplicate deliveries.
- Name an owner and a monthly line for monitoring and vendor changes.
What the business decides
Which system owns customers, invoices and orders. Which tax codes and accounts each kind of transaction maps to. What happens to an order whose customer does not exist in accounting. Who receives the error queue and how quickly it must be cleared. These are business decisions dressed as technical ones, and an integration built without them encodes a developer’s guess.
What this means for you
Accounting, CRM and payments are the integrations your application will need, and each is a small project with a known trap. Decide sources of truth and mappings with the business, use hosted payment flows and verified webhooks, make writes idempotent, log everything, route errors to a person and budget a monthly line. Built that way they run for years; built quickly they duplicate an invoice on the first slow afternoon.
Frequently asked questions
Which system should be the source of truth?
One per kind of data, decided before building: customers usually in the CRM, invoices and payments in accounting, orders in the application. Other systems read from the source or receive copies, never both write the same field. Most integration disputes trace back to two systems each believing they own a record.
Why do payment integrations need special care?
Money and compliance. A duplicate charge, a missed refund or a payment marked paid when it failed damages customers and trust immediately. Providers offer hosted checkout flows and signed webhooks precisely so that your code never touches card data and can verify every event. Use them and test every failure path.
How much maintenance do integrations need?
A little, continuously: monitoring for failures and silence, updates when a vendor versions its API, checks when either system's fields change. Budget a small monthly line and a named owner. Integrations that are never touched stop working the day a vendor ships a change.
Sources
- Stripe documentation: Webhooks (accessed 2026-09-12)