What Payshen does,one part at a time.

Pin a provider, set an order, set a fallback, exclude one, cap an amount. Or let the engine choose among what is eligible by approval likelihood, cost, latency, or a balance of the three, per country and method.

Rules are versioned. A draft never touches live traffic; you publish when you are ready, and every version stays readable.

A second provider is tried only when the first result cannot later become a charge: a technical failure that definitely did not execute, or a soft decline. A timeout, an unknown answer, a hard decline, a fraud block or a compliance refusal never cascade.

Every attempt is recorded with its class, so you can see what the engine did and why it stopped.

Every payment passes through named states, and every change is written to a ledger with what the provider said, who asked, and why. Captured is not settled. Unknown is not declined.

A capture, cancellation or refund the provider has only accepted stays pending until the provider confirms it, by callback or when Payshen asks. The merchant hears about it once, when it is true.

The transaction page shows it like a statement, in words.

Every connection is one row: its status, its approval rate against your other connections, attempts and response time, the last callback it sent and whether its settlements are in. One set of words is used everywhere: needs credentials, not tested, test failed, working, degraded, resting, paused.

A provider that keeps failing is rested automatically and payments go to your others meanwhile; one payment tries it again before traffic returns. When a connection test fails, the row says what the provider answered and which setting to fix.

Every workspace has test keys and live keys, and test payments never reach a live account. From a connection's menu, "Send test payment" sends a small test payment through that connection only, opens the provider's own payment page, and then shows a checklist that fills in as the provider confirms each step: created, paid, callback received and verified, then capture, cancel and refund on demand.

If the provider's callbacks are being refused, for example because the signing secret is missing, the checklist says so and links to the field that fixes it.

One API for all of them. A card acquirer answers in the call; a bank rail sends the customer to their bank and answers later; both look the same to your integration: a status, a next action, a webhook.

Collect on your own checkout or send the customer to a hosted page - your choice. With the browser package you mount the routed provider's own card fields in your page; the card is tokenized there, so it never reaches your servers or ours, and the same integration falls back to a redirect when a provider has no in-page fields.

Every state change is an event with a stable id, delivered signed. Verify the signature, claim the id, act once. The SDK does all three in one call.

Every delivery is visible: what was sent, what your endpoint answered, when it was retried.

Every fee says where it came from: learned from the provider's own settlements, your contract if you enter it, or the provider's published list price until then. A fee nobody knows is shown as unknown, never as a guess. With effective dates and tiers, that gives the expected cost of a payment before it is routed. Settlement gives the actual cost after. The difference is variance you can act on.

Savings are only ever compared against providers that could have taken the payment, and measured savings are kept apart from estimated opportunity.

Insights ranks findings by the money they are about: a provider approving a country worse than another, declines nobody retried elsewhere, fees above your contract, refunds or disputes rising, a provider slowing down. Each names the estimate, its confidence and sample size, why it was shown, and one action that goes where it is fixed. Snooze or dismiss what you have decided against.

Analytics has the numbers behind them, compared with the previous period, and every row opens the payments it counts. Nothing is applied for you outside the guardrails you set.

Start a test from any rule: another route gets the share of traffic you choose, the rest keep the current routing, and the same customer or order always lands on the same side. Results say how many more or fewer payments the test route approved and what it cost, with the number of payments behind each figure.

Safety limits stop a test on their own when the test route approves clearly less. When it clearly earns more it becomes the rule in a new published version, or you make it the rule yourself; the previous version stays a rollback away, and every step is in the audit trail.

Settlements arrive by provider sync where the provider offers one, or by uploading its settlement file. Each line is matched to its payment; what does not match is listed as an exception you can resolve, match by hand or detach, with the reason recorded.

Fees in the settlement become the payment's actual cost, which is what cost intelligence compares against the expected one.

Disputes arrive from the provider with their reason and deadline. Draft your evidence, attach files and notes, and submit it from Payshen where the provider supports it; elsewhere Payshen keeps the record and the deadline while you answer in the provider's own dashboard.

For an inquiry that has not become a chargeback yet, refunding instead is one action, and it is recorded on the dispute.

Apply to a provider through Payshen with a reusable profile and document vault. The provider reviews, asks, and decides in their own portal. The decision is always theirs; the record of it is always yours.

When approved, the connection appears with the terms the provider set, and routing enforces them.

Nine roles with server-enforced capabilities, from owner to viewer. Every action in an append-only audit trail. Test and live kept apart in keys, data and screens.