Every part of orchestrating a payment, and nothing it does not need.

One amount, fixed on the server, paid on a page that asks nothing more.

• One checkout is one amount. The amount is fixed when the checkout is created, on the server, from your own systems: an amount in minor units, a currency and your own reference. Asking again for the same reference while the checkout is open returns the same checkout, so a retry never double-charges.
• The hosted page carries the merchant. It opens with the merchant's logo or initial in the merchant's brand colour, the amount the server fixed, and the payment methods the merchant's connection offers. Paying needs no script of its own.
• Every outcome is written down for the payer. The waiting, paid, failed and expired screens each say what happened and what to do next. A paid page keeps its receipt code, so a payer can point at it later.
• Attempts stay separate from the total. A checkout may be tried more than once, but only one attempt can succeed. A provider that answers twice cannot collect twice.

A way to be paid that starts in chat.

• Fixed amount, own record. A link carries its own amount and description, and the payments it produced are listed against it and exported as one CSV.
• Kept honest by caps. A link can refuse itself once it has collected what it says it would, and it can be switched off the moment it should stop.

A provider account joins with a document, not code.

• Connector documents only. The engine reads a versioned document that describes the provider: how the credential is carried, the call that starts a collection, how the answer is read, and how callbacks are verified. The engine has no special case for any provider.
• Test money first. Every connection is exercised through its sandbox until the business and its details are cleared, and live money waits for its own explicit switch on the merchant's page.
• Egress that proves itself. The engine declares every provider origin it may call, and the host allows nothing else. Calls to providers leave from fixed, published addresses.
• Health feeds routing. Connections are probed and scored; a failing provider is routed around while payers are shown the methods that still work.

What is kept is enough to settle an argument later.

• State machines, not guesswork. Checkouts, attempts and refunds move through published contract states with an append-only history, and status queries reconcile the open ones against the provider.
• Webhooks that can be verified. Deliveries carry an HMAC signature bound to a timestamp, are retried with backoff, and can be replayed in order for each object.
• Refunds that match what was paid. A refund is bounded by what the provider confirmed was collected; a refund handled outside the engine, such as cash, is recorded with the name of whoever handled it.
• Statements and reconciliation. Finished days are closed, provider reports are imported and matched, and the exceptions that remain are assigned and resolved one by one.

Two tools, one look, no spreadsheets.

• Merchant dashboard. Payments, refunds, statements, analytics, links, connections and keys, per business, with a test-mode chip wherever no real money moves.
• Back office. The platform view: merchants, partners, markets, reconciliation, audit, kill switches, and the runbooks the alerts link to.
• Guarded access. Sign-in is delegated to ifinsta.com's identity service; pay keeps its own sessions and no passwords. Step-up is required where real money moves.