> ## Documentation Index
> Fetch the complete documentation index at: https://docs.onecluster.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Step 6: Go Live: Request Production Access
> Everything you need to move from sandbox testing to real transactions
This is Step 6 of 6 in the onboarding journey. [View the full onboarding overview →](/onboarding/overview)
You've registered your company, verified your identity, received your sandbox API key, and built and tested your integration. That's a significant amount of work, and you're now one step away from handling real transactions for real customers.
This step covers what you need to do before applying, what happens during the review, and what to expect after you go live.
***
## What production access means
Production is the live banking environment. When you're live:
* Virtual accounts you create are **real bank accounts** backed by Union Bank, with real NUBAN (Nigerian Uniform Bank Account Number) account numbers that can receive deposits from any Nigerian bank
* Payments you initiate are **real money transfers** over the NIP (Nigeria Instant Payment) network. They can't be reversed once they clear.
* Customers who use your product are **real people** whose money you're responsible for
That's why the review exists. A brief wait now protects your customers, your business, and the broader financial system from integration errors that could cause real financial harm.
There's no "undo" in production. A payment sent to the wrong account, a virtual account created with incorrect details, or a webhook handler that fails silently can have real financial consequences. The go-live checklist exists precisely to help you catch these issues before they affect real people.
***
## Prerequisites: complete this checklist before applying
Don't submit your production access request until every item on this list is complete. Our review team will check for evidence of each item.
**Completed at least one full end-to-end test for each product you're requesting access to.** For example, if you want access to both Payments and Virtual Accounts, you should have tested the full flow for each: creating an account, funding it (in sandbox), initiating a payment, and handling the resulting webhooks, all the way through to your own application's response.
**Set up HTTPS-only webhook endpoints.** A webhook endpoint is a URL on your server that we send notifications to when events happen (for example, "a payment was received" or "a transfer completed"). Webhooks must be served over HTTPS. HTTP isn't accepted in production. Your endpoint must return a `200 OK` status within 30 seconds of receiving a notification. See the [Webhooks product guide](/products/webhooks) for implementation details.
**Tested your webhook handler.** Use the sandbox webhook simulation tool to send test events to your endpoint and confirm your handler processes them correctly, including failure scenarios (duplicate events, out-of-order delivery, malformed payloads).
**Stored your API keys in environment variables or a secret manager, not in code or in Git.** See [Step 5: API Keys](/onboarding/api-keys) for guidance on secure key storage.
**Implemented idempotency keys on all write operations.** An **idempotency key** is a unique string you include in the header of every request that creates or modifies data (`POST`, `PUT`, `DELETE`). If your network drops and you retry a request, the idempotency key tells our system "this is the same request you already processed, don't do it again." Without idempotency keys, a network retry can create duplicate payments or accounts. Use a UUID (a randomly generated unique identifier. Most programming languages have a library for this) as the idempotency key for each unique operation.
**Implemented retry logic with exponential backoff.** If an API request fails with a `5xx` error (a server-side error), your code should automatically retry the request after a short delay. **Exponential backoff** means each retry waits longer than the previous one. For example, wait 1 second, then 2, then 4, then 8. This prevents your system from overwhelming ours during an incident and improves your resilience to transient failures.
**Know your server's outbound IP addresses.** When your production access is approved, we add your server's IP addresses to our allowlist: a list of addresses permitted to make production API calls. You'll provide these addresses in your application. If your IP addresses change (for example, if you move hosting providers), contact us to update the allowlist.
**Set up monitoring and alerts for your integration.** You should have dashboards or alerts that notify you if your API error rate increases, your webhook handler fails, or your response times degrade. The sandbox is the time to set this up. Don't figure it out after go-live.
**Defined your incident response process.** Know what you'll do if something goes wrong in production. Who gets paged? What's the escalation path? How do you reach UBN BaaS support? Our support email is [baas-support@unionbank.ng](mailto:baas-support@unionbank.ng).
**Reviewed the rate limits for your production tier.** Production rate limits differ from sandbox limits. Confirm your expected peak request volume fits within your approved production tier. See [Rate Limits](/security/rate-limits) for details.
***
## How to submit your production access request
Submit your production access request from the portal at [ubn-ui.onecluster.co](https://ubn-ui.onecluster.co). Open the **Production Access** section and fill in the form. You'll need:
| Field | Description |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Products** | The API products you're requesting production access to. Valid values: `accounts`, `payments`, `collections`, `kyc`. Only request products you've actually tested in sandbox. |
| **Business justification** | A description of your use case in at least 50 words. Explain what your product does, who your customers are, why you need each product you're requesting, and your expected transaction volumes. More detail here reduces back-and-forth and speeds up approval. |
| **Server IP addresses** | The outbound IP addresses of your production servers. These are added to the production API allowlist. All production API calls must originate from these IPs. |
| **Webhook URLs** | The HTTPS URLs where you want to receive production webhook notifications. They must be reachable from the public internet and must return `200 OK`. |
| **VPN Connection Form reference** | Conditional. The reference number of your completed VPN Connection Form. Required if your use case involves high-volume payments or your UBN relationship manager has advised you to set up a VPN connection. |
**Example business justification:**
> TechFin Limited operates a savings and investment platform serving retail customers in Nigeria. We require virtual accounts to give each customer a unique collection account tied to their savings wallet, payments capability to process customer withdrawal requests to their bank accounts, and collections to receive customer deposits. We currently serve 8,000 registered users in sandbox testing and are preparing for a public launch.
### What is the VPN Connection Form?
A **VPN (Virtual Private Network) Connection Form** is a document provided by your UBN relationship manager that sets up a secure, encrypted private network connection between your servers and UBN's infrastructure.
A standard HTTPS API connection over the public internet is secure for most use cases. A VPN connection goes further. It routes your API traffic through a private, dedicated network channel that bypasses the public internet entirely. This is required for partners with very high transaction volumes, partners handling particularly sensitive data, or partners whose risk profile or use case warrants the additional security layer.
Your UBN relationship manager will tell you whether you need a VPN connection. If you haven't been assigned a relationship manager, email [baas-support@unionbank.ng](mailto:baas-support@unionbank.ng) with your `partnerId` and "VPN Connection" in the subject line.
***
## What happens during the review
After you submit your request, your application goes through a structured review process. Target review time is **2 to 5 business days**.
Our team confirms your application is complete: all required fields are present, your IP addresses are valid, your webhook URLs are reachable, and your business justification meets the minimum detail requirement.
If anything is missing or incomplete, you'll get an email within 24 hours asking for the specific information needed. Responding promptly keeps the process moving.
A technical reviewer examines your sandbox activity to confirm:
* You have actually tested the products you're requesting access to
* Your integration handles error cases correctly (not just happy paths)
* Your webhook handler has been exercised with various event types
* Your usage patterns don't suggest incomplete or unstable implementation
Our security team reviews your server IP addresses, webhook URLs, and any information provided about your security setup. They may ask follow-up questions about your infrastructure, key management, or data handling practices.
When the review is complete and approved, our team:
* Issues your production API key
* Adds your server IP addresses to the production allowlist
* Configures your VPN connection (if applicable)
* Activates your production webhook endpoints
* Sends you a confirmation email with your production key and go-live instructions
***
## What happens when you're approved
You'll get an email from `noreply@unionbank.ng` with the subject **"UBN BaaS: Production access approved"**. The email contains:
* Your production API key (shown once, save it immediately)
* Confirmation of which products are enabled
* Your production rate limits
* The UBN BaaS support contacts for production issues
* A link to the [Incident Response](/resources/support) page
At this point, your production API key is active and you can make live API calls to `https://api.onecluster.co`.
***
## What happens if more information is needed
If our team needs clarification or additional information, you'll get an email with specific questions. Common examples:
* "Please describe your expected peak daily payment volume"
* "Please confirm how you'll handle customer disputes for payments"
* "Your webhook URL returned a 404 during our test, please confirm it's live"
Responding to these questions promptly keeps your review on track. Most requests resolve within 1 additional business day.
***
## Post-go-live: staying healthy in production
Going live isn't the end. It's the beginning. Here are the most important things to do in the days and weeks after your launch.
Set up a dashboard or alert that fires if your API error rate (HTTP `4xx` or `5xx` responses) rises above your baseline. A sudden increase in errors is usually the first signal of a problem. Catching it early prevents it from affecting many customers.
Key metrics to track:
* API error rate (percentage of requests returning errors)
* Webhook delivery failure rate
* Payment failure rate (separate from API errors. A payment can succeed at the API level and fail at the banking network level.)
* Response time (latency above 5 seconds on synchronous endpoints usually indicates a problem)
UBN BaaS retries failed webhook deliveries up to 5 times with exponential backoff. But if your webhook endpoint is down for an extended period, you may miss events.
Best practices:
* Queue incoming webhook events rather than processing them synchronously. This prevents your webhook handler from timing out.
* Store raw webhook payloads before processing. If your processing logic has a bug, you can replay the stored payloads after fixing it.
* Alert yourself if your webhook endpoint returns non-`200` responses more than a handful of times per hour
For production incidents (live transactions failing, unexpected API behaviour, suspected security issues):
* **Email:** [baas-support@unionbank.ng](mailto:baas-support@unionbank.ng). Include your `partnerId`, the affected endpoint, a sample request ID, and the time the issue started.
* **Subject line format:** `[PROD INCIDENT] Brief description`. This flags the email for priority handling.
For non-urgent questions, documentation feedback, or general queries, use the same email address. Just omit the `[PROD INCIDENT]` prefix.
Production API keys should be rotated at least every 90 days. See [Step 5: API Keys](/onboarding/api-keys) for the rotation process. The 72-hour grace period makes this straightforward to do without any downtime.
Set a calendar reminder now, before you forget.
If you change hosting providers, add new servers, or move to a different cloud region, your outbound IP addresses will change. Contact [baas-support@unionbank.ng](mailto:baas-support@unionbank.ng) before making infrastructure changes to update your allowlist. API calls from unlisted IP addresses are blocked.
***
You've completed the full UBN BaaS onboarding journey. Welcome to production.
If you haven't already, explore the product guides to get the most out of your integration:
Create and manage real Nigerian bank accounts programmatically.
Send money to any Nigerian bank account over the NIP network.
Receive money from customers with unique collection accounts.
Get real-time notifications for every event in your integration.