Pehmen Docs
Pehmen sits over your existing payment stack. It decides whether a payment or a payout should happen, records why, and instructs a licensed provider to act. It never holds money.
If you run a platform that onboards sellers (event organizers, resellers, merchants) and pays them out, Pehmen gives you a record of who is being paid, a decision on every movement of money, and a file when something goes wrong. Everything in the dashboard is read back from records the platform wrote at the time. Nothing is recomputed for the screen.
Operators · payments, risk, payout operations
→The manual. What each screen shows, what each button does, what refuses you and why. From a fresh account to a routed test payment, alone, in under thirty minutes.
Decision makers · founders, CTOs, heads of risk and finance
→What Pehmen does, what it never does, how it protects a payout, how it is secured and hosted, how it compares to what you have, and what a pilot looks like. Plain language, no claims the product cannot back.
Developers · the people wiring the checkout and the payouts
→One REST API, three headers, an idempotency key on every mutation, Ed25519-signed webhooks. Quickstart in curl or Node with no dependencies, an integration guide, the runtime architecture, and the full reference.
The shape of the product
Three things happen inside the box, and each one leaves a record you can open later:
- A record of who is being paid. Every seller has a registry entry, an attestation of how they were verified, and one or more tokenized payout destinations. Changing a destination is slow on purpose: a cooling-off window, a notification to the old and the new channel, and a second person's approval.
- A decision on every movement. Payments and payouts pass through the Gate, which answers with one of six words (
ALLOW,STEP_UP,HOLD,REROUTE,REVIEW,DENY) and reason codes from a fixed registry. Payments are then routed to one of your connected providers, and the full trace of that choice is stored with the payment. - A file when something goes wrong. Cases hold hashed evidence, a ledger of what was done to whom, and an appeal path a seller can use without an account.
Test and Live
Every workspace starts in the Test environment, on your own provider sandbox credentials. Live is a separate set of connections, data and policies, gated by an entitlement that no workspace holds today. A live key pasted into a test connection is refused before it is stored. There is no promote-to-live switch anywhere in the product. How Test and Live relate.
Looking for something specific
| If you want to… | Read |
|---|---|
| Get from a fresh account to a routed test payment | Your first routed payment |
| Understand a screen you are looking at | The Screens section, one page per dashboard screen |
| Know what a status word or a reason code means | Statuses and Reason codes |
| Integrate from your own server | Developer center |
| See how the system is put together | Runtime architecture |
| Find out why a button is refusing you | Roles and guards and Troubleshooting |
| Get a straight answer to a common question | FAQ |
Pehmen is not scam-proof, does not hold or protect consumer funds, and does not act as merchant of record. Every protective behaviour described here comes from your own data, your own rules, and the verification steps the workflow enforces.