Yasir KhanSolutions Architect
ArticlesIntegrations

Payments, identity checks and fraud: integrations that do not fail silently

Yasir KhanOctober 20263 min read

On a car financing platform, a customer can verify their identity, choose a car, pick finance and insurance products and sign a contract without visiting the dealership. Behind that flow sit a payment provider, identity and fraud checks, inventory feeds and delivery vendors. Each one is a system you do not control.

I led engineering on platforms like this, with integrations including Stripe and Plaid, fraud and KYC providers and inventory systems. The lesson that matters most is simple: an integration is not done when the happy path works. It is done when every way it can fail is handled on purpose.

1. Put every provider behind your own interface

The rest of the product should talk to "payments" or "identity check", never directly to a vendor's SDK. That keeps provider quirks in one place, makes testing possible without the real service, and means a provider can be replaced without touching every screen that uses it.

2. Make money movements safe to repeat

Networks drop requests. Users click twice. Every call that moves money carries an idempotency key, so a retry can never charge a customer twice. The same applies to webhooks: they arrive late, out of order and more than once, so they are verified, stored and processed in a way that tolerates duplicates.

3. Treat timeouts as a normal day

Every outside call has a timeout, a retry with backoff for the errors that are worth retrying, and a clear state for the user when the answer is "not yet". A loan application stuck behind a slow fraud check should say it is being reviewed, not freeze.

4. Keep what the provider told you

Store the raw responses from identity, fraud and payment providers alongside your own decision. When a customer or a regulator asks why something happened, the answer is in your own records, not in a vendor dashboard you may no longer have access to.

5. Reconcile, do not assume

A scheduled job compares your records with the provider's: payments captured, refunds issued, checks completed. Differences become alerts for a person, which is far cheaper than a customer finding them first.

6. Make the state visible to the people who run the business

Dealers and operations teams need to see where each deal stands: identity verified, credit checked, payment pending, contract signed. A clear status for every step turns most support calls into a glance at a screen.

The integrations a customer never notices are the ones that were designed for the day something went wrong.

The same approach carries straight over to AI agents. A model provider is one more outside system that can be slow, wrong or unavailable, and it deserves the same discipline as a payment gateway.