Are payouts automatic for every merchant?

No. Payout behavior is policy-governed and deployment-specific. Many programs include operator review, holds, or staged enablement.

Is payout the same as settlement?

No. Settlement recognition and outbound payout are distinct operational stages—see the settlement vs payout guide.

What evidence should finance retain?

Lifecycle transitions, operator approvals, payout identifiers, and reconciliation notes—aligned with your internal audit policy.

How do we discuss payout scope with Kobbopay?

Include outbound use case, required rails, and approval model in your request access submission after reading onboarding expectations.

Merchant payout infrastructure

Operational overview

Inbound payment infrastructure gets most engineering attention; payout infrastructure determines whether treasury can move funds safely at scale. Confusing settlement with payout creates audit risk and support incidents.

Merchant payout programs need explicit vocabulary: when funds may leave, who approves, what evidence is retained, and how payout states relate to recognized settlement.

Kobbopay emphasizes reviewed merchant access and selected rails—payout capabilities and review requirements are deployment-specific after approval.

Integration and control concepts

Server-side integrations should treat payout initiation as a privileged action—never expose payout authority in client applications or public repositories.

Webhook and API reads may reflect payout progression, but policy gates (operator review, limits, holds) belong in operational runbooks finance signs off on.

Idempotency matters for payout requests as it does for payment creation—duplicate commands must not create duplicate outbound movements.

Rails and policy scope

Outbound movement is rail-specific: fees, confirmation behavior, and treasury posting differ by network and asset.

Enabled payout corridors are agreed per merchant environment. This site does not publish a universal payout asset list.

Use settlement vs payout guide and merchant payout review playbook when designing internal approvals.

Settlement, recognition, and payout

Settlement recognition answers when finance may treat inbound funds as recognized; payout answers when outbound movement is authorized.

Collapsing those stages silently causes teams to ship goods, recognize revenue, or release funds on the wrong signal.

Reconciliation jobs should tie payout records to settlement evidence and operator decisions—not only to explorer screenshots.

Webhooks, security, and auditability

Payout state changes may arrive through the same control plane as inbound payments—verify webhooks on raw bytes and restrict operational tools with least privilege.

Security review should include who can initiate payouts, how holds are represented, and what logs finance can audit during period close.

See crypto webhook security for inbound control-plane patterns that also apply when payout events share delivery infrastructure.

Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.

Walkthroughs: /operations

Reviewed merchant onboarding
Server-side API keys only
Signed webhook verification on raw bytes
Explicit lifecycle states
Operational reconciliation model
No client-side secrets

If this model matches your B2B program, align engineering and treasury on lifecycle semantics, complete reviewed merchant onboarding preparation, run webhook verification tests in the first environment you receive, then submit a structured access request with required rails and use case context.

Request access Read integration docs

Frequently asked questions

Are payouts automatic for every merchant?: No. Payout behavior is policy-governed and deployment-specific. Many programs include operator review, holds, or staged enablement.
Is payout the same as settlement?: No. Settlement recognition and outbound payout are distinct operational stages—see the settlement vs payout guide.
What evidence should finance retain?: Lifecycle transitions, operator approvals, payout identifiers, and reconciliation notes—aligned with your internal audit policy.
How do we discuss payout scope with Kobbopay?: Include outbound use case, required rails, and approval model in your request access submission after reading onboarding expectations.