Go-Live Checklist

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. API and environment setup

Before you go live, the Vivamo team will configure your operator account and provide you with production API keys.

Once your account is configured, verify the following:

• Production API keys suitably stored — 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.
• Publishable key configured in SDK — The clientKey option in the SDK setup uses your production publishable key.
• Standard SDK 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).

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.

3. KYC verification

Vivamo supports two production paths for KYC: SDK-enforced (no operator work — KYC is launched automatically during the customer's first payment or disbursement) and operator-initiated (you call Get Customer KYC Info and mount createKycElements yourself, for example at signup). See KYC Verification. Check the items below that apply to your path.

• KYC initiation implemented (operator-initiated path only) — Your system calls Get Customer KYC Info to retrieve the clientSecretKey before the customer reaches a payment or disbursement form.
• SDK widget mounted (operator-initiated path only) — Your frontend passes the clientSecretKey to vivamo.createKycElements() and handles the kyc-completed event. Both verified and verified_manually are treated as success; any other status should surface an error or retry.
• Fresh state on every load — Your system does not cache clientSecretKey values or KYC status. It calls Get Customer KYC Info each time it needs the current state.
• KYC webhook handler built (if webhooks implemented) — Your endpoint handles eventType: "kyc_verification" and processes every terminal status: verified, verified_manually, rejected, rejected_manually, expired, and under_review.

4. Payments and disbursements

• 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.

5. Personal tax compliance

• Prizing endpoint implemented — If your tax type requires prizing submissions (e.g. bingo, or horse_racing), your backend implements the POST /v1/prizing endpoint. See Personal Tax.
• 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)

• 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 gracefully. For any unrecognized types, it still returns 200 without error.

7. Geolocation and compliance

• Geolocation rules confirmed — Your location restrictions are confirmed with Vivamo and states or regions are blocked. See Geolocation.
• Blocked request messaging — Your UI shows a clear message to customers in restricted locations rather than a generic error.

8. Error handling

• API errors handled — Your integration parses error responses and maps HTTP status codes to user-friendly messages. See Error Handling.

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.

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.

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)