Compared to what you have
Your provider moves money, an orchestrator picks which provider, a fraud vendor scores the buyer; Pehmen decides whether and when seller money should be released at all, and keeps the record.
Written for anyone asking 'do we not already have this?'.
The short table
| Holds funds | Decides who gets paid | Decides when | Second-person controls | Keeps the reasoning | |
|---|---|---|---|---|---|
| Payment provider (Stripe Connect, Adyen, HitPay, Airwallex) | Yes, licensed | No, executes your instruction | No | Sometimes, in their dashboard | Their logs, their shape |
| Payment orchestrator | No | Picks the provider per transaction | No | No | The switch decision |
| Fraud vendor | No | Scores the buyer's card | No | No | A risk score |
| Manual ops and a spreadsheet | No | A person | A person | If someone remembers | Whatever was typed |
| Pehmen | Never | Your rules, per seller and destination | Cooling-off, evidence, release as a separate act | Enforced by the software | Every candidate, filter and reason, stored at the time |
Against a payment provider
The provider is the execution rail. It is licensed to hold and move money and it does that correctly. Pehmen drives it: when your rules say ALLOW and two people have acted, Pehmen sends the provider an instruction. The provider's own dashboard will show you the transfer; it will not show you why it was allowed, what the alternatives were, or who approved the change of destination three days earlier. Pehmen keeps your provider. Nothing about your contract with them changes.
Against an orchestrator
An orchestrator answers which provider should carry this payment. Pehmen answers that too, for payments, with a routing engine whose every choice is stored: the candidates, the nine hard filters each passed or failed, the score. But routing is the smaller half. The larger half is the trust workflow around payouts and destinations, which an orchestrator does not have, because an orchestrator sells the switch.
Against a fraud vendor
A fraud vendor scores the buyer at checkout: is this card, this device, this session likely to be fraudulent? That is a card-not-present problem. Pehmen's problem is on the other side of the marketplace: is this seller who they say they are, is this destination theirs, should this payout go out now. The two are complementary; a fraud score can be one input to a Pehmen rule, and Pehmen does nothing to replace one.
Against manual operations
This is the real incumbent. Someone checks new sellers. Someone notices a bank account changed. Someone holds a payout when an event looks off. It works until it is 11pm, or the person is on leave, or the attacker is patient. Pehmen turns each of those habits into a check the software refuses to skip, and turns the spreadsheet into records written by the system at the time, with the reason attached. The savings simulation in the product replays your own imported history through a rule set and reports what it would have held, so the comparison against your current practice can be run on your data rather than argued.
What only this does
Every routed payment stores the candidates it considered, the filters each passed or failed, and the arithmetic that picked the winner, and the screen renders that record rather than recomputing it. Money movement is a workflow with a cooling-off window, dual approval and out-of-band notices, not a call. Those two properties are the product; the rest is what any competent system should do.