Understand the operating model before you integrate.
Answers covering merchant approval, API security, provider credentials, balances, settlements and the four launch rails.
Merchant onboarding
Who can apply for a FABS merchant account?+
Legally registered businesses with clear ownership, a supported business model and verified settlement beneficiaries may apply.
What information is required?+
Company details, directors, beneficial owners, expected volumes, target markets, requested rails and compliance documents.
Does an application guarantee approval?+
No. Every application is reviewed against provider rules, programme terms and risk requirements.
APIs and credentials
Do merchants receive the master MID or provider API secret?+
No. FABS issues merchant-scoped keys. Master MIDs and provider secrets remain server-side.
Can one key access another merchant’s data?+
No. Every request resolves to one merchant and approved scopes.
How are duplicate requests prevented?+
Money-moving requests require idempotency keys so safe retries return the original operation.
Balances and settlement
Where do customer payments arrive?+
The provider processes the payment into the approved platform account structure, while FABS attributes it to the correct merchant ledger.
When can a merchant withdraw?+
Only available balance may be requested. Pending funds, reserves and holds are excluded.
How are payouts protected?+
Beneficiaries are verified and withdrawals require operational approval before connector execution.
Payment channels
Which rails are covered?+
Visa and Mastercard, M‑Pesa, bank transfer or ACH, and USDT TRC20.
Are every bank and rail live immediately?+
No. Each rail requires a contract, credentials, webhook mapping and UAT sign-off.
Does FABS store crypto private keys?+
The intended model uses a managed provider; private keys should not be stored in the application database.