Entity and product review
The contracting company completes KYB and explains its product, ownership, customer journey, distribution channels and revenue model. Approval is scoped to that reviewed use case.
Infrastructure for fintechs
Build payments into your financial product. Connect the customer experience.
ZyndPay gives approved fintechs product-level building blocks for collections, custodial stablecoin accounts, payouts, signed events and reconciliation. The exact capabilities and compliance split are agreed during onboarding; the services available to your business are defined during review.
- API-first integration
- Custody stated plainly
- Agreed integration scope
Operating model first
A fintech integration begins with who serves the customer and who moves the money.
Before technical work becomes live processing, both teams map the legal entities, users, funds flow, currencies, markets, custody model, customer support and compliance responsibilities. A clean diagram prevents a payment API from being mistaken for a licence or a complete regulated operating model.
Customer and compliance split
The parties identify who onboards and supports the end user, which KYC or KYB path applies, who performs required screening and who handles complaints, disputes and regulatory requests.
Custody and balance language
Where ZyndPay provides a consumer balance, it is custodial and not a bank deposit. A partner must not relabel that balance as self-custody, insured savings or its own banking product.
Country and rail readiness
A supported API concept does not guarantee every country, asset, network or payout destination. Live availability follows enabled account configuration and the current operating status of each rail.
Architecture path
Connect customer actions to verified payment results.
The fintech owns its product experience while ZyndPay exposes approved payment concepts and states. Stable identifiers, idempotent instructions and signed events keep the two systems aligned without treating a screen transition as ledger truth.
- 01
Map the funds flow
Document money in, account or custody state, conversions, holds, payouts and money out. Identify the legal owner and evidence source at each transition before choosing an API path.
- 02
Prove the path in sandbox
Use supported test flows to model creation, pending, success, failure and event retries without moving real money. Sandbox acceptance is not approval for live processing.
- 03
Create idempotent instructions
Give each payment or payout a stable business key and handle retries without duplicating economic effect. Keep request acceptance distinct from final rail completion.
- 04
Consume signed state changes
Verify and process signed asynchronous events, tolerate replay and recover from downtime by reconciling authenticated state rather than trusting event arrival alone.
- 05
Reconcile before scaling
Compare the fintech’s customer records, ZyndPay transaction and ledger evidence, and external-rail outcomes. Resolve unexplained differences before increasing volume or automation.
Building blocks
Use only the blocks your approved product actually needs.
Payment acceptance
Create supported collection flows with stablecoin, card or mobile-money methods when enabled for the account and transaction context.
Custodial stablecoin accounts
Support approved USDT or USDC balance journeys in ZyndPay’s custodial model, with enabled asset-network pairs and explicit withdrawal controls.
Payout instructions
Submit eligible money-out instructions and observe screening, approval, processing and terminal states without presenting acceptance as delivery.
Signed webhooks
Connect asynchronous payment state to the fintech back end with signed events, retries and replay-aware consumption.
Sandbox and promotion path
Exercise product-level test scenarios first, then complete KYB, operating review, credentials and account configuration before live use.
Ledger-aware reconciliation
Keep customer display, transaction state, fees, refunds, settlement and payout evidence related but distinct in operational reporting.
Regulatory boundary
An API connection does not transfer every regulated responsibility.
The contract and approved operating model define the responsibility split. ZyndPay does not grant the fintech a banking licence, certify its regulatory status, or make unsupported white-label and licence-cover claims. Each party remains accountable for the duties it owns.
- Customer promise
- Describe custody, availability, fees and finality exactly as implemented. Do not promise insured deposits, guaranteed value, universal instant settlement or self-custody when those are not the product.
- Compliance evidence
- Retain the onboarding, consent, screening and transaction evidence required by the agreed model. A successful API response does not prove the partner met its own obligations.
- Commercial evidence
- Pricing, limits, settlement and enabled rails are account-specific and disclosed before live processing. No public universal fintech rate card applies.
Technical entry points
Explore the public concepts, then unlock private implementation details after signup.
Payments API
Understand the public lifecycle for creating and tracking supported collection and money-out flows.
Explore the payments APISigned webhooks
Design idempotent, replay-aware consumers for asynchronous payment and payout status.
Explore webhooksSandbox
Model success, failure and retry behavior without treating a test environment as live approval.
Explore the sandboxFAQ
Questions from fintech teams
Is ZyndPay a banking-as-a-service provider?
This page does not make that claim. ZyndPay provides approved payment, custodial stablecoin, payout and related product capabilities. The legal and compliance responsibilities for a fintech use case are defined during qualification and in contract.
Can a fintech embed ZyndPay balances in its own app?
Only through an approved product and operating model. Where a consumer balance exists it is custodial, not a bank deposit or self-custody wallet, and the user, support, KYC, custody and disclosure responsibilities must be explicit.
Can integration start before KYB is complete?
Supported sandbox work can begin before live approval. Real-money processing, production credentials and enabled rails remain gated by KYB, operating review and account configuration.
Does one API mean every rail is available everywhere?
No. The integration model can be consistent while actual assets, networks, countries, payment methods and payout destinations remain account- and transaction-specific.
How should retries and webhooks be handled?
Use stable idempotency keys for instructions, verify signed events, tolerate retries and replay, and reconcile authenticated state after downtime. Never turn duplicate delivery into duplicate money movement.
Does ZyndPay publish fintech pricing?
No universal public rate applies. Pricing, limits and settlement terms are provided for the qualified account in the relevant dashboard, API response or commercial terms before live processing.
Architecture and qualification
Plan your payment integration with our team.
Share the legal entities, target users, markets, currencies, custody and money-out model, expected volumes, compliance owner and technical owner. That lets both teams define the smallest truthful product boundary before implementation.