Stripe Payments Connector

The problem

A business taking card payments through Stripe has two accurate sets of records that do not agree with each other. Stripe knows every charge, refund, dispute and fee to the cent. Dynamics 365 Finance & Operations knows every invoice and customer balance. Between them sits a payout: one bank deposit representing hundreds of charges, minus refunds, minus processing fees, occasionally minus a dispute, arriving days after the transactions themselves.

So somebody exports a CSV each week, matches charges to invoices by hand, works out which payout covers which transactions, posts a lump sum, and books the fee difference to a suspense account that nobody reconciles until year end. Customer accounts show payments late or not at all. Credit control chases customers who already paid. When a dispute lands, the reversal is discovered from a bank statement.

What ECOSIRE builds

A build-to-order X++ extension for Finance and Supply Chain Management — extension classes, table and form extensions, event handlers, no overlayering — that keeps Stripe activity and F&O in agreement automatically, and makes the bank deposit reconcile to the cent.

Transaction ingestion

A batch framework job pulls Stripe objects on a schedule: charges and payment intents, refunds, disputes, balance transactions and payouts. Ingestion is cursor-based and idempotent, keyed on the Stripe object ID, so a rerun or an overlapping window cannot double-post. Where you prefer near-real-time behaviour, a webhook endpoint can be exposed and the signature verified before anything is written; every webhook event is still reconciled against a scheduled pull, because a missed webhook must never mean a missing payment.

Staging and matching

Stripe activity lands in a staging table with its raw payload, its object ID and a status. Matching then links each charge to the right F&O record using a configurable strategy: invoice number carried in Stripe metadata, payment intent ID stamped on the sales order at checkout, customer reference, or amount-and-date within a tolerance. Confident matches proceed automatically; ambiguous ones queue for review in a workspace with the candidate records shown side by side. Unmatched charges are never guessed into place.

Posting into the ledger

Matched charges create customer payment journal lines against the correct customer account, in the correct legal entity, with the ledger dimensions your configuration requires. Refunds post as credits linked to the original transaction rather than as free-standing entries. Disputes post a reversal on the dispute and, where the dispute is later won, an offsetting entry, so the customer balance follows the real outcome instead of jumping. Processing fees post to the expense account you nominate rather than disappearing into the gross amount. Currency is handled explicitly: presentment currency, settlement currency and your accounting currency are held separately, with exchange differences posted to the account you specify.

Payout reconciliation — the part that matters

Each Stripe payout is imported with its full balance-transaction breakdown, and the connector builds the arithmetic that proves it: gross charges, less refunds, less fees, less disputed amounts, equals the deposit that hits your bank. A payout reconciliation form shows that bridge line by line and flags any component that has no matching F&O entry. The payout can then be settled against the clearing account so that the bank statement line for the deposit reconciles cleanly in Advanced bank reconciliation instead of being force-matched.

Controls and visibility

A workspace shows ingestion status, unmatched transactions, review queue depth, unreconciled payouts and last successful sync. Failed API calls retry with bounded exponential backoff and honour Stripe's rate limiting rather than retrying immediately. The Stripe secret key is held in a secrets store your administrators control and referenced by handle, never written to a transactional table, and it is redacted in logs. New security privileges and duties let you separate configuring the connector from reviewing matches from posting journals, and all of it can go through your existing F&O workflow approvals before posting if your controls require it.

Who this is for

Subscription, digital and e-commerce businesses running F&O that already take card payments through Stripe; finance teams whose month-end is held up by card reconciliation; and organizations where credit control is chasing customers who have already paid because the payment has not reached the customer account. It fits equally where volume is high enough that manual matching has become a full-time job, and where volume is modest but the fee and dispute accounting has never been clean.

How delivery works

1. Scoping call. We look at how customers pay you today, what metadata your checkout writes to Stripe, your legal entity and currency setup, which accounts fees and disputes should post to, your invoicing pattern (order-based, subscription, or invoice-first), and whether you want scheduled polling, webhooks, or both. 2. Fixed quote. A written scope with a fixed price and a delivery window. Typical lead time is two to four weeks from approved scope. If your checkout does not currently write an invoice or order reference into Stripe metadata, we will tell you at this stage, because it materially changes match rates. 3. Build. Developed in our F&O development environment against your target platform and application version, tested against Stripe test-mode data including refunds, partial refunds, disputes and multi-currency payouts. 4. Install in test. The deployable package goes into your sandbox through LCS, configured against your Stripe test keys. We run a full cycle — charge, refund, dispute, payout — and reconcile it with your finance team so they see the arithmetic before it touches production. 5. Production. Promoted through your release pipeline. Live keys are configured by your administrators. We recommend running the first live payout cycles alongside your existing manual process as a parallel run. 6. Support. A defect-correction warranty window after go-live, with optional ongoing support for API version changes and platform updates.

What this is not

ECOSIRE is not a payment processor and takes no part in the money movement — your Stripe account, your agreement, your keys, your funds. No card data enters F&O; the connector works with Stripe object IDs and amounts. It is not an instant download: each build is fitted to your entity structure, currencies, chart of accounts and checkout metadata.