Shop systems in which payment, stock and order record agree.

What this involves

• Catalogue and stock stay in the system that owns them

  Products, variants, availability and pricing rules stay in the system of record you name; the shop reads them instead of keeping a second version that is right on Monday and wrong on Friday.

• Payment paths on your own provider accounts

  Card payments through Stripe, bitcoin payments through BTCPay Server, configured against the accounts and contracts that are yours. The money moves between your customer and you; we are not in that path and never hold the funds.

• Order states that survive a callback arriving twice

  A payment confirmed twice must not ship twice. Provider callbacks are handled idempotently, keyed on the reference the provider sends, and configured against the behaviour a provider actually shows rather than the one its documentation describes.

• Invoices, refunds and the corrections afterwards

  Invoices through Invoice Ninja, partial refunds, cancellations and corrections after the fact — the part where being approximately right is the same as being wrong, and the part most shop configurations leave to somebody with a spreadsheet.

• A reconciliation you can run without us

  A scheduled comparison between what the provider says it settled and what your order records say, with the differences listed instead of summed away. It runs on your side, so nobody has to ask us to look.