Skip to main content

The vocabulary

The dashboard is a dossier. Every screen is a record of something that happened, written by the platform at the time and shown as written. These are the words on those records.

Workspace, environment, merchant account​

Workspace is your organization. Everything below belongs to exactly one workspace. Its id starts with org_.

Environment is test or live. Connections, payments, policies, webhooks and keys are all bound to one environment. Nothing crosses. Today every workspace lives in test. See Test and Live.

Merchant account is the routing scope inside a workspace and environment. Connections belong to a merchant account, and routing only ever considers connections on the same account as the payment.

Connection​

A connection is one provider credential you pasted (Stripe restricted test key, HitPay sandbox key, or Airwallex client id and key), validated against the provider, then encrypted under the workspace master key. Only a connector worker can unwrap it. The dashboard shows a fingerprint (eight hex characters), never the key.

A connection has a flow type: PAYIN (takes payments: Stripe, HitPay) or PAYOUT (sends money: Airwallex).

Order, payment intent, attempt​

An order is what is being bought: your order reference, amount, currency, category, channel, customer and seller references.

A payment intent is the decision to collect for that order. It starts CREATED. Nothing is routed until you confirm it.

An attempt is one hand-off to a provider. Confirming reserves exactly one attempt on the connection the router picked. A soft decline may add a second attempt on the same connection. A collected card never moves to a different provider.

Route decision and Gate decision​

When you confirm, two things are written:

  • The Gate decision (also called the risk decision) is the published TRUST and ROUTING policies' verdict: one of ALLOW, STEP_UP, HOLD, REROUTE, REVIEW, DENY, with reason codes and the exact policy version.
  • The route decision is the routing engine's record: every connection considered, the nine hard filters each passed or failed, the arithmetic that scored the survivors, and the winner. The payment page renders this record. It does not recompute it.

Policy​

A policy version is a JSON rule set of type TRUST (evaluates beneficiary changes and payouts) or ROUTING (evaluates payment intents). Versions are immutable. The one in force is the published head. Getting there is a lifecycle: draft, validate, replay, submit, a second person approves, publish with a fresh second factor. Rollback goes through the same dual control.

Seller, beneficiary, beneficiary change​

A seller is a party you pay. It carries a verification level (UNVERIFIED, BASIC, REVIEWED, VERIFIED) that only an operator attestation can raise.

A beneficiary is a payout destination. The account number is never stored. What is stored is a masked form, a tenant-keyed fingerprint, and what the provider said about the account holder's name.

A beneficiary change is a request to point a seller at a different destination. It waits out a cooling-off window (24 hours by default, 72 when the Gate holds it), notifies the old and the new verified channel, and needs a second person's approval with a fresh second factor.

Payout instruction​

A payout instruction tells a licensed provider to send money to a beneficiary. The Gate evaluates it on creation. ALLOW makes it APPROVED; anything else holds it with the reasons. Approving and releasing are separate acts by separate permissions. Above the dual-control threshold, approval needs two people. Release is the only call that moves money.

Case, evidence, action, appeal​

A case is a file about a seller, order, payment, payout or change. Evidence is stored with a SHA-256 hash and provenance, and is tombstoned rather than deleted. Actions (restrict a seller, hold a payout) record the state they replaced so a reversal is a restore. An appeal is the seller's way in, through a single-use link that needs no account.

Reconciliation exception​

When a provider's settlement report and Pehmen's payout records disagree, or a record is missing on either side, a typed exception is opened. It has an owner, an age, and one of four statuses. Matching is by reference, never by amount.

Second factor and step-up​

The actions that touch credentials or money refuse unless you verified a second factor within the last few minutes. The dashboard asks for the code inline. See Roles and guards.

Dual control​

Some actions need two different people: publishing a policy, approving a beneficiary change, approving a payout above the threshold. The person who asks can never be the person who approves. The approval is bound to the exact content that was reviewed, so if anything changes in between, the approval is stale and refused.