Product
The method,capability by capability.
Route each payment to the provider most likely to approve it, cascade safely when one says no, and read the reason for every decision. Your contracts, your settlement, your money. Never ours.
- Reach
- Every provider you use or want, cards, Open Banking, APMs and local rails, through one API and one console.
- Certainty
- Eligibility before routing; cascading only when the first attempt cannot charge twice; an unknown outcome is never reported as a decline; every decision explained, every exclusion named.
- Economics
- Cost intelligence that separates measured from estimated; recommendations with impact, confidence and evidence; always inside your policy.
01 / 10
Eligibility before routing
Before any provider is scored, every one that cannot take the payment is removed: wrong currency, wrong payer country, a method it does not offer, an industry it does not accept, an amount outside its limits, or a term from its own approval of you. Each exclusion carries a code and a sentence.
A machine can branch on the code. A person can act on the sentence. And the dry run on the routing page uses the same function as live traffic, so a preview cannot say yes where a payment would be refused.
Why it mattersA refusal you cannot explain costs a sale and a support ticket at once.
02 / 10
Routing you can steer
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.
Why it mattersYour policy wins over any score, every time.
03 / 10
Cascading that cannot charge twice
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.
Why it mattersThe wrong retry is a double charge with your name on it.
04 / 10
A lifecycle you can read
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.
The transaction page shows it like a statement, in words.
Why it mattersFinancial truth is a record, not a status column.
05 / 10
Cards, Open Banking, alternative methods, local rails
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.
Hosted flows carry the customer to the provider's page and back. Card data never touches Payshen.
Why it mattersReach without a second integration.
06 / 10
Webhooks and events
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.
Why it mattersAt-least-once delivery is only safe if you can deduplicate, so we make that the easy path.
07 / 10
Cost intelligence
Your contracted fees per provider, with effective dates and tiers, give 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.
Why it mattersThe cheapest provider that would have declined is not a saving.
08 / 10
Recommendations, not homework
A recommendation names the change, the estimated monthly impact, its confidence, three facts behind it and the traffic it affects. Preview it, apply it, or dismiss it. What you applied is measured against what was predicted.
Nothing is applied for you outside the guardrails you set.
Why it mattersDecisions, with the evidence attached.
09 / 10
Onboarding and the marketplace
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.
Why it mattersOne application profile. Many providers.
10 / 10
Team, roles and audit
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.
Why it mattersControl is a property of the system, not a promise.