Bind identity to payout destination
Confirm that the intended recipient controls the selected destination before execution.
PassID Connect establishes a trusted customer relationship. PassID Pay reuses its eligible evidence for a specific transaction, binds merchant authorization and recipient consent, then issues a signed record — without repeating the original verification.
The public sandbox uses synthetic identities, simulated accounts, and a simulated payment adapter. It does not initiate or settle real payments.
USD · ACH sandbox · simulated provider
Create the intent. Northstar authorizes the payout; Maya consents and confirms destination on the hosted page.
Northstar Work authorized this payout. Maya consents to evidence reuse and confirms the destination in a secure hosted session — this console cannot do that for her.
Consent and destination confirmation are bound to the immutable payment terms. The sandbox adapter is now simulating provider execution. No live funds are moving.
PassID issued a signed, status-aware record of the payment context and simulated outcome. It contains a pairwise subject identifier and only the authorized claims.
This credential records a sandbox event. It is not evidence that real funds were transferred or settled.
Atlas Rentals requests proof that Maya received verified contractor income during the last 30 days.
No credential results were shared, no destination was confirmed, and no payment instruction was sent.
PassID Pay is built first for repeated contractor and marketplace payouts — the exact flow running in the sandbox above.
Recurring payouts to workers and sellers where destination confirmation and reusable consent matter every cycle.
Confirm that the intended recipient controls the selected destination before execution.
Require fresh confirmation when payout instructions change after authorization.
Reuse eligible credential results with new consent instead of rebuilding the same evidence.
Keep institution authorization, recipient consent, policy evaluation, provider events, and transaction evidence together.
Integrate through a stable PassID contract while licensed partners execute the underlying payment.
Receive the required result without automatically collecting bank statements, raw transactions, or account numbers.
Identity and account binding, policy evaluation, recipient consent, destination confirmation, provider orchestration, signed transaction evidence, credential status, and auditability.
Executing and settling real payments, operating the applicable payment rail, and performing the regulated activities assigned to them by contract and applicable law.
Payment approval, customer relationships, institution policy, required compliance decisions, dispute responsibilities, and the final use of PassID evidence.
A bank, deposit account, stored-value wallet, everyday checkout product, hidden credit score, or claim that a transaction is fraud-free.
Sandbox: pay_test_ keys. Production rails remain limited to approved use cases and licensed providers. Connect and Verify keys are rejected.
POST /v1/pay/payment-intents
GET /v1/pay/payment-intents/{id}
POST /v1/pay/payment-intents/{id}/merchant-authorize
POST /v1/pay/payment-intents/{id}/consent
POST /v1/pay/payment-intents/{id}/confirm-destination
POST /v1/pay/payment-intents/{id}/execute
// Authorization: Bearer pay_test_…
// Sandbox: sandbox-api.passid.io · Production: api.passid.io
Production access is limited to approved use cases supported by licensed payment providers — we review every application and reply directly, no automated queue.