Third-Party Integrations

What crosses the wire

• Where it sits

  Downstream of the payment. A charge happens first, and the integration carries its result — the transaction, the fee, the refund, the deposit — into the system that needs it for bookkeeping, reporting or customer history.

• What crosses

  Settled transactions with their fees, refunds against the original sale, and deposit records that name the batch behind them. Accounting integrations care about the deposit; CRM and booking integrations care about the customer and the reference.

• What has to be mapped first

  Your chart of accounts, or the equivalent structure in the target system. Fees, refunds and chargebacks each need a home, and an integration configured before that decision is made produces a tidy set of wrongly categorised entries.

When to use it

• Month-end takes days

  When someone reconciles deposits to transactions by hand, the integration pays for itself in the first close rather than in the first year.

• Two systems disagree

  A payment tool and an accounting ledger that were maintained separately will drift. Connecting them makes the drift visible immediately rather than at year end.

• Customer history lives elsewhere

  A CRM or booking system that knows what a customer paid, and when, answers support questions without a second lookup in a payments dashboard.

How to implement Third-Party Integrations

What fails, and how you find out

• Gross and net confused

  A deposit is the sale minus the fee. Posting the deposit as revenue understates income and hides the cost of processing, and the error compounds quietly across a year.

• Duplicate entries after a retry

  If the integration re-posts a period it already posted, the ledger doubles. Reconciling the first cycle by hand is what catches this while it is still one period rather than twelve.

• Refunds posted as new expenses

  A refund belongs against the original sale, not as an unrelated outflow. Mapped wrongly, revenue and expense both inflate and the net looks correct, which is why nobody notices.

• A revoked connection nobody watches

  Tokens expire and permissions get withdrawn when staff change. An integration that silently stopped syncing is discovered at close, so alert on the absence of expected entries.

Sandbox versus production

• Accelerated settlement makes the cycle testable

  Accounting integrations depend on deposits, which on production follow your funding schedule. Sandbox compresses that, so a full sale-to-deposit-to-entry cycle can be checked in one sitting.

• Use a test company file

  Where the target system offers a sandbox or a test company, connect to that rather than to live books. An integration mapped wrongly against real accounting data is much harder to unwind than to prevent.

• Sandbox amounts are not your rates

  Fees shown against sandbox transactions are illustrative. Map the structure with them, but validate the actual amounts against your first real settlement.