SUPPORT CENTRE
Answers for building with FCMB BaaS
Find practical guidance for onboarding, API access, wallets, virtual accounts, and transfers.
Getting started
Accounts, environments, and access
FCMB BaaS gives businesses API access to banking capabilities such as customer verification, wallets, virtual accounts, collections, and transfers. This lets you embed financial services into your own product while managing operations from the BaaS dashboard.
FCMB BaaS is intended for registered businesses that want to integrate financial services into their products. Your organization must complete the required business onboarding and compliance checks before production access is approved.
Create an organization account, complete your business profile and KYB application, invite the relevant team members, then generate test credentials from the dashboard. Build and validate your integration in the Test environment before requesting Live access.
The Test environment uses simulated data and has no financial impact, so it is the right place to build and verify your integration. The Live environment processes real transactions and becomes available after your integration and KYB compliance checks have been approved.
KYB applications are reviewed to confirm your business and compliance information. Check the dashboard for feedback or missing documents. If all requested information has been supplied and the status has not changed, contact support with your organization name.
API integration
Authentication, credentials, and responses
Send your client ID and client secret to the token endpoint as application/x-www-form-urlencoded data using the client_credentials grant type and profile scope. Use the returned access token as a Bearer token on subsequent API requests.
Open Developer Tools in the dashboard and select API Keys. Credentials and base URLs are environment-specific, so confirm that you are using Test credentials with the Test URL or Live credentials with the Live URL.
Keep client secrets on your server and store them in a secure secrets manager or protected environment variables. Never expose a client secret in browser code, mobile applications, public repositories, logs, or screenshots.
UNAUTHORIZED usually means the access token is missing, invalid, or no longer accepted. FORBIDDEN means the authenticated client does not have permission for that operation. Request a fresh token, verify the environment and credentials, then confirm that the required product access is enabled.
Check both the top-level validation status and the operation status inside the response data. A valid request can still return a PENDING or FAILED operation. Keep the returned reference and use the relevant status-query endpoint rather than immediately repeating the transaction.
Wallets and accounts
Customer wallets and virtual accounts
| Tier | Daily outgoing limit | Maximum wallet balance | Requirements |
|---|---|---|---|
| Tier 1 | ₦50,000 | ₦300,000 | Basic information and BVN/NIN |
| Tier 2 | ₦200,000 | ₦500,000 | BVN and NIN |
| Tier 3 | ₦5,000,000 | Unlimited | Tier 2 requirements, verified address, and utility-bill image |
Daily outgoing limit: The maximum total amount that can be sent from the wallet in a day. It is not a maximum wallet balance or funding limit.
Maximum wallet balance: The highest amount that can be held in the wallet at any time. For example, a Tier 1 wallet with ₦150,000 can receive another ₦150,000 before reaching its ₦300,000 limit.
Tier 3 creation includes asynchronous verification of the submitted address and utility bill. Keep the reference returned by the request and use the Tier Three Creation Status endpoint to check the outcome. Do not create another wallet while verification is still processing.
Yes. The API provides separate upgrade operations from Tier 1 to Tier 2 and from Tier 2 to Tier 3. Supply the additional verification information required for the destination tier and use the upgrade status endpoint where the verification is asynchronous.
A static virtual account is retained for repeated collections and can be mapped to a customer or purpose. A dynamic virtual account is created for a specific collection flow. Choose the account type that matches how you identify and reconcile incoming payments.
Yes. Depending on your permissions, the wallet APIs support placing or removing a lien, blocking or unblocking debits, freezing or unfreezing a wallet, and closing a wallet with a supported closure reason.
Transfers and support
Payments, reconciliation, and help
Do not retry immediately. Save the client reference you supplied, or the reference returned by the API, and query the transfer status. Retrying before checking can create a duplicate request or make reconciliation harder.
Generate a unique client reference for each transfer and persist it before sending the request. Reuse that reference only when querying the original transaction. If a request times out, check its status before deciding whether to submit another transfer.
Use the payment simulation endpoint in the Test environment to simulate a payment into a wallet. Test credentials and simulated transactions must not be used against the Live base URL.
Store the references returned by wallet, virtual account, and transfer operations. Use transaction history, virtual account receipt, transfer query, and account statement endpoints to match API operations with your internal records.
Review the API documentation and capture the environment, endpoint, timestamp, HTTP status, and request or transaction reference. Do not include API secrets or sensitive customer data. Send those details to help@getrova.com so the support team can investigate.
Still need help?
Send our support team the details of your question or integration issue.