Going live
What to have in place before your production environment takes real payments.
Your production environment is separate from sandbox in every way: its own keys, connections, credentials, routing policy and webhook endpoints. Nothing carries over, so going live means setting each of these up deliberately.
Get production access from each provider
Production access is between you and the provider. What each integrated provider needs:
Without a contract, production runs in restricted mode (own accounts only).
Production Payment Initiation needs Plaid's approval of the use case; VRP is enabled separately.
Under Yapily Connect, Yapily is the regulated party and the platform shows Yapily's disclosure; payments are capped at £15,000.
Each provider's page in the marketplace says who the regulated party is. With your own contract you stay the provider's customer, and Unirail acts as your technical service provider.
Put live credentials in your vault
Lay out /unirail/<railId>/<KEY> in your production Infisical environment, then repeat Connect Infisical with OIDC for the production environment. It has its own subject, so it needs its own machine identity, with read access to the production environment only.
Add production connections
In production, add each provider with provider environment production. A live environment refuses sandbox connections, and the reverse. Set the non-secret configuration each provider needs on the connection, such as redirect URIs and app identifiers registered with the provider, and run the connection's check.
Set the routing policy
Decide which connections are eligible in which countries, and at which stage: internal and beta let you start small before ga. Choose the custody kinds you admit; admit only none if your platform must never be in the flow of funds. Every policy change takes a reason, so the history explains itself.
Create a live key and a webhook endpoint
Create a ur_live_sk_… secret key in production and put it in your production secrets, never in a client. Add a production webhook endpoint with its own signing secret, then use Send test to check your handler verifies it.
Check your integration handles the edges
- Every write carries an idempotency key derived from your own record.
quote_expiredandquote_changedsend the user back to choose again.- Your user's approval is bound to the quote's
idanddigest. - Webhook handling dedupes on
webhook-id, and a job walks/v1/eventsto catch anything missed. account.reauth_requiredprompts the user to link again.
Put the paperwork in place
Unirail processes personal data on your behalf (names, account identifiers, device context), so put a data processing agreement in place before live data flows.