Support
/
Go-Live Checklist

Go-Live Checklist

Verify your integration is production-ready before going live

This checklist covers what you need to confirm before Vivamo approves your integration for production. Work through each section and skip any that don't apply. When you've checked everything off, reach out to the Vivamo team to get your account approved for production.

1. Account and environment setup

Before you start building, the Vivamo team will configure your operator account during onboarding. Confirm the following settings are in place:

  • Payment processors — Which processors are active on your account, along with credentials and any surcharge settings.
  • Payment orchestration rules — Routing rules and distribution ratios per country and payment method.
  • KYC verification settings — Whether KYC is enabled, the verification type, minimum age requirement, and whether verification is required for payments, disbursements, or both.
  • Sales tax — Which US states have sales tax applied to transactions.
  • Personal tax type — The IRS reporting type for your use case (W-2G for bingo, W-2G for horse racing, 1099, or none).
  • Geolocation rules — Which states or regions are blocked from transacting.
  • Email notification preferences — Whether receipt and disbursement status emails are sent to customers always, never, or based on intent settings.
  • Token storage limits — Maximum number of saved card and bank tokens per customer.

Contact the Vivamo team to finalize these settings before you begin integration. Changes to these settings after launch require coordination with Vivamo.

Once your account is configured, verify the following:

  • Operator account confirmed — You have access to your production operator account.
  • Business information on file — Legal entity name, contact details, and compliance documentation are submitted to Vivamo.
  • Production API keys obtained — You have your secret key and publishable key for production. The secret key is stored on your backend and never exposed to the client. See Authorization.
  • Production URLs configured — Your integration points to https://api.vivamo.co, not the sandbox URL. See Environment Setup.
  • SDK initialized for production — The Vivamo SDK is loaded from https://sdk.vivamo.co/v1 and initialized without { environment: "test" }. See Vivamo SDK.

2. Customer integration

  • Customer creation implemented — Your backend creates customer records via POST /v1/customers before initiating transactions.
  • Required fields provided — Every customer record includes an externalCustomerId and email. See Customers.
  • Email restrictions handled — Your system accounts for production rules: disposable email domains and + suffix addresses are rejected.
  • Additional data included where possible — First name, last name, phone number, and address let the SDK pre-fill fields so customers don't have to enter them during payment.
  • KYC Verification handled - If KYC is enabled, customer creation includes the verifyAfterCreation: true flag, and your system then initiates the verification flow. See KYC Verification.

3. KYC verification

Skip this section if KYC verification is not enabled for your operator account.

  • KYC initiation implemented — Your system starts verifications on customer creation (using verifyAfterCreation) or using the Get Customer KYC Info endpoint to retrieve the verification URL and present it to customers. See KYC Verification.
  • Verification link delivered — You present the verification URL to customers through your app (embed or new window), email, or another channel, and prevent customers from proceeding if verification is not completed.
  • KYC webhook handler built (if webhooks implemented) — Your webhook endpoint handles eventType: "kyc_verification" events and processes all outcomes: verified, under_review, and rejected.
  • Expiration handled — KYC links expire after 1 hour. Your system does not store these links, instead retrieves a valid verification URL via Get Customer KYC Info.

4. Payments and disbursements

If your integration only includes payments or only includes disbursements, skip the items that don't apply.

  • Payment intent creation implemented — Your backend creates intents via POST /v1/payment-intents. See Payments.
  • Disbursement intent creation implemented — Your backend creates intents via POST /v1/disbursement-intents. See Disbursements.
  • SDK launched with client secret — The clientSecretKey from the intent response is passed to the Vivamo SDK on your frontend.
  • Transaction webhook handler built (if webhooks implemented) — Your endpoint handles eventType: "transaction" for both transactionType: "payment" and transactionType: "disbursement". See Webhooks.
  • Failed transaction statuses handled — Your system handles failed and declined outcomes and shows the subStatus reason to customers where appropriate.
  • Surcharges displayed (if applicable) — If your integration includes processing fees, the SDK shows the breakdown (base amount, fees, total) before the customer confirms.
  • Pending validation handled (disbursements only) — Your system listens for pending-validation status and uses the proceed endpoint to approve or reject.
  • Bank account linking tested (disbursements only) — Customers can link bank accounts through the SDK and complete a disbursement end-to-end.

5. Personal tax compliance

Skip this section if W-9 tax reporting is not enabled for your operator account.

  • W-9 webhook handlers built (if webhooks implemented) — Your system handles customer_w9_required and customer_w9_completed event types. See Personal Tax.
  • W-9 collection flow tested — You've run through the W-9 flow in sandbox and confirmed your system responds to both webhook events.

6. Webhooks (optional)

Webhooks are optional but recommended. They let your system react to transaction status changes, KYC outcomes, and tax events in real time. Skip this section if your integration does not use webhooks.

  • Webhook endpoint registered — Your production URL is registered via POST /v1/operators/webhooks. See Webhooks.
  • Webhook secret stored — The secret from the registration response is stored on your backend for signature verification.
  • Signature verification implemented — Your endpoint verifies the HMAC-SHA512 signature header on every incoming webhook before processing.
  • Endpoint returns 200 — Your handler returns 200 to acknowledge receipt. Any other response triggers retries.
  • Retry behavior understood — Vivamo retries failed deliveries up to 5 times with delays of 1, 2, 3, 4, and 5 minutes.
  • All relevant event types handled — Your handler processes every event type your integration uses: transaction, kyc_verification, customer_w9_required, and customer_w9_completed.

7. Geolocation and compliance

  • Geolocation rules confirmed — You've reviewed your location restrictions with Vivamo and confirmed which states or regions are blocked. See Geolocation.
  • Blocked location messaging — Your UI shows a clear message to customers in restricted locations rather than a generic error.
  • VPN detection understood — Vivamo blocks transactions from detected VPN connections by default. Show customers a message explaining why the transaction was blocked.

8. Error handling

  • API errors handled — Your integration parses error responses and maps HTTP status codes to user-friendly messages. See Error Handling.
  • Validation errors surfaced — When the API returns a 400 with a validation error array, your system extracts and displays the relevant messages.

9. SDK readiness

  • SDK integration follows the guide — Your frontend integration matches the setup described in Vivamo SDK, including element creation, mounting, and event handling.
  • Screenshots provided — You've shared screenshots of your payment flow and disbursement flow (if applicable) with the Vivamo team, showing the SDK elements as they appear in your app.
  • Standard functionality intact — Custom CSS or styling does not remove, hide, or disable any standard SDK elements, buttons, or informational displays (e.g., fee breakdowns, payment method selectors, trust badges).

10. Testing

  • Payment flow tested end-to-end — You've completed at least one full payment in sandbox: intent creation, SDK interaction, and processing.
  • Disbursement flow tested — Full disbursement in sandbox, including the approval step.
  • KYC flow tested (if applicable) — Verification initiated, completed, and webhook received with the outcome.
  • Webhook delivery verified (if webhooks implemented) — Your endpoint receives webhooks from sandbox and processes them correctly.
  • Edge cases tested — Declined payments, expired intents, blocked geolocation, and other failure scenarios relevant to your integration.

11. Production readiness

  • Production keys and URLs in place — Your deployment uses production API keys and the https://api.vivamo.co backend endpoint. The frontend SDK is loaded from https://sdk.vivamo.co/v1, and does not include the {"environment": "test"} configuration.
  • Webhook endpoint publicly accessible (if webhooks implemented) — Your production webhook URL is reachable from the internet, not behind a firewall that blocks inbound requests.

What Vivamo may request

Before approving your account for production, the Vivamo team may ask you to share any of the following via email, Slack, or screenshots:

  • A screen recording or screenshots of your end-to-end payment flow
  • A screen recording or screenshots of your disbursement flow
  • Test transaction IDs from sandbox
  • Webhook delivery logs showing successful receipt and processing (if webhooks implemented)

Ready to go live? Contact support@vivamo.co to let the Vivamo team know. They'll confirm your setup and approve your account for production transactions.

Built with