Skip to main content
Production activation verifies your integrating business. It is separate from the API customers you create for your product.

​
Activate your production space

  1. Sign in to the Swipelux Dashboard and select Create a production space.
  2. Open the KYB tab or go to Business verification.
  3. Complete every requested field and upload the required documents.
  4. Submit your integrating business for verification and wait for approval.
Only after your integrating business KYB is approved can you create production API customers and transactions. In a live space that requires KYB, Swipelux returns 422 merchant_kyb_not_approved for every write request outside business verification and webhook management until approval. This includes customers, capabilities, accounts, recipients, rules, quotes, and transfers. While you wait for approval, you can still:
  • Send GET and HEAD requests.
  • Complete your business verification (profile, related parties, documents, and task submissions for your business’s KYB customer).
  • Manage webhook endpoints through the API, and manage secret keys, spaces, and rail fees in the dashboard.
Settings have limits until approval:
  • You can make 20 webhook URL changes per hour in total, across all endpoints in your live spaces that require KYB. Changes in sandbox spaces do not count. Exceeding the webhook URL limit returns 422 merchant_kyb_not_approved from POST /v3/webhooks or PATCH /v3/webhooks/{webhookId}.
  • In the dashboard, you can have up to 10 active API keys per live space that requires KYB.
  • In the dashboard, you can have up to 5 spaces per merchant while you have at least one live space, all your live spaces require KYB, and none is approved. This counts both sandbox and live spaces. If any live space does not require KYB, this space limit does not apply.
The dashboard refuses requests that exceed the key or space limit with a plain 422 response, without the merchant_kyb_not_approved code. Changing only an endpoint’s events, or saving its current URL, does not count as a URL change. Revoked API keys do not count toward the key limit. Sandbox spaces are exempt from the write block, webhook URL limit, and key limit, so you can keep building and testing there. They still count toward the merchant’s space limit.

​
Keep production independent

Create production resources explicitly. Changing an API key does not migrate sandbox state. A sandbox key cannot reach production resources. See Key scope.
  • Store production credentials in a separate secret-manager entry.
  • Use production-only deployment configuration and resource IDs.
  • Register a separate production webhook endpoint and signing secret.
  • Recreate the required customers, capabilities, accounts, recipients, and destinations in production.
  • Restrict production access to the services and operators that need it.
Sandbox and production use https://platform.swipelux.com; the API key selects the environment.

​
Complete the launch checklist

  • Test the happy path and expected failure paths in sandbox.
  • Send an Idempotency-Key with every write that requires one and retain it for safe retries.
  • Verify webhook signatures before parsing, persist event IDs durably, and test replay.
  • Handle unavailable capabilities, open tasks, and changed task revisions.
  • Handle documented API errors and retries, including idempotent retries with the original key.
  • Surface transfer failures and actionable instructions to your operators.
  • Confirm logs retain X-Request-Id or correlationId without exposing secrets or sensitive financial data.

​
Run one controlled live flow

Start with a known customer and one low-value transaction. Record: Verify both the current API resource and the authenticated webhook delivery. If either differs from the expected result, stop and investigate before sending more traffic. After the complete flow succeeds, increase volume gradually while monitoring capability, account, destination, and transfer states. Return to Common flows for the product journey, review Errors and retries for failure handling, or use the API Reference for exact contracts.