# Go live

> Everything to check before you start taking real card-present payments with VINR.

Work through each section in this checklist in order before processing your first live card-present transaction. Skipping steps — particularly the compliance and integration checks — can result in declined payments, settlement holds, or PCI audit findings that are costly to remediate after go-live.

> Live card-present processing must be explicitly enabled on your account. Contact your VINR account manager to turn on live mode before completing this checklist — attempting to process real cards without live mode enabled will result in hard declines on every terminal.

## Account and compliance

Confirm every item before touching a terminal.

> VINR terminals are PCI PTS 5.x certified and participate in a P2PE solution — encryption keys are injected at the factory and are never accessible to you or your staff. This materially reduces your PCI scope, but does not eliminate it. See [PCI DSS](/docs/compliance/pci-dss) for the full scope reduction details.

## Terminal setup

Complete this section for every terminal in your deployment.

> Supported terminal models and their printer and connectivity capabilities:
>
> | Model        | Form factor                     | Printer  | Connectivity          |
> | ------------ | ------------------------------- | -------- | --------------------- |
> | Nexgo N92    | Android handheld                | Built-in | 4G / WiFi / Bluetooth |
> | Nexgo N86Pro | Android handheld (large screen) | None     | 4G / WiFi / Bluetooth |
> | Nexgo CT20   | Desktop countertop              | Built-in | Ethernet / WiFi       |
> | Nexgo CT20P  | Desktop countertop with PIN pad | Built-in | Ethernet / WiFi       |
> | Ciontek CM30 | Compact Android mPOS            | None     | Bluetooth / WiFi      |
>
> All five models support contactless (NFC), chip+PIN, and magnetic stripe.

## Integration (skip for standalone)

Complete this section only if your terminals are connected to a backend via the Terminal API. If you are running in standalone mode — configuring everything from the dashboard with no custom code — skip to [Feature verification](#feature-verification).

##### SDK setup

```typescript
import { Vinr } from '@vinr/sdk';

const vinr = new Vinr({ secretKey: process.env.VINR_SECRET_KEY });

const terminalPayment = await vinr.terminal.payments.create({
  terminalId: 'term_01HZ5QXYZ',
  amount: 2500,
  currency: 'USD',
  reference: 'order_8821',
});
```

Confirm `process.env.VINR_SECRET_KEY` resolves to a `sk_live_…` key in your production environment before deploying.

##### Webhook handler

```typescript
import { Vinr } from '@vinr/sdk';

const vinr = new Vinr({ secretKey: process.env.VINR_SECRET_KEY });

export async function POST(request: Request) {
  const rawBody = await request.text();
  const signature = request.headers.get('vinr-signature') ?? '';

  const event = vinr.webhooks.constructEvent(
    rawBody,
    signature,
    process.env.VINR_WEBHOOK_SECRET,
  );

  if (event.type === 'payment.completed') {
    await fulfillOrder(event.data.reference, event.data.amountCaptured);
  }

  if (event.type === 'payment.failed') {
    await notifyStaff(event.data.reference, event.data.declineCode);
  }

  return new Response(null, { status: 200 });
}
```

Always call `vinr.webhooks.constructEvent` and verify the signature before acting on a payload. See [Webhooks](/docs/integration/webhooks) for retry behaviour and failure handling.

## Feature verification

For each optional feature you have enabled, run the test described below on a live terminal before opening to customers. Features not in your acquiring agreement do not need to be verified.

| Field          | Type         | Description                                                                                                                                                                                                                                              | Default |
| -------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `Tipping`      | `If enabled` | Create a payment with tip.mode: 'on\_screen'. Confirm the tip selection screen appears on the terminal before the card prompt. Verify the captured amount includes the selected tip.                                                                     | `—`     |
| `Surcharge`    | `If enabled` | Present a card type subject to surcharge. Confirm the surcharge amount is disclosed on the terminal screen before the customer approves. Check the payment object's surcharge field in the dashboard. See Surcharging for legal disclosure requirements. | `—`     |
| `Cashback`     | `If enabled` | Process a debit card transaction with a cashback amount. Confirm the terminal prompts for the cashback amount and that the total (purchase + cashback) appears correctly on the receipt.                                                                 | `—`     |
| `MOTO`         | `If enabled` | Process a key-entered card-not-present transaction via the terminal MOTO flow. Confirm the card number entry screen appears and that the resulting payment is flagged as card\_not\_present in the dashboard.                                            | `—`     |
| `Installments` | `If enabled` | Present an issuer-eligible card and select an installment plan on the terminal. Confirm the plan terms appear before authorization and that the payment object includes an installments field in the dashboard.                                          | `—`     |

## Test transactions

Run this sequence on each terminal model in your deployment before going live.

**Insert a test card and process a small live transaction**

Use a real, low-value card (or a dedicated test card issued by your bank) to process a transaction of the smallest denomination that clears on your acquiring account — typically the equivalent of $0.01 to $1.00. Perform this on each distinct terminal model: Nexgo N92, Nexgo N86Pro, Nexgo CT20, Nexgo CT20P, and Ciontek CM30 as applicable.

**Verify the receipt**

Confirm a receipt is produced — printed on devices with a built-in printer (N92, CT20, CT20P), or delivered digitally on devices without one (N86Pro, CM30). Check that the merchant name, amount, card last four, and a transaction reference are all present.

**Confirm in the dashboard**

Open Dashboard → Payments and locate the transaction. Verify the status is `completed`, the amount matches, and the terminal ID is correct. If your integration attaches metadata or a reference, confirm those fields are populated.

**Issue a test refund**

Initiate a refund against the transaction — either via the terminal app, the dashboard, or your integration using `vinr.refunds.create`. Confirm the refund appears under the original payment with status `succeeded` and that a refund receipt is delivered.

> Do not process test transactions above the minimum required to verify the flow. These are real authorizations against a live acquiring account and will appear on the cardholder's statement.

## Monitoring

Set up alerting before your first live shift so that issues surface immediately rather than at end-of-day reconciliation.

See [Monitoring and alerts](/docs/operations/monitoring-and-alerts) for the full alert configuration reference and webhook event schema.

#### Advanced — Fleet health monitoring and automated remediation

For deployments with multiple locations and many terminals, use the Terminal Management API to build automated monitoring.

```typescript
import { Vinr } from '@vinr/sdk';

const vinr = new Vinr({ secretKey: process.env.VINR_SECRET_KEY });

const terminals = await vinr.terminals.list({ locationId: 'loc_7Xk4p' });

const offline = terminals.data.filter(t => t.status === 'offline');

for (const terminal of offline) {
  await vinr.terminals.reboot(terminal.id);
  await alertOncall(`Rebooted offline terminal ${terminal.label} (${terminal.id})`);
}
```

Subscribe to `terminal.offline` and `terminal.online` webhook events to build a real-time device health feed. Pair with the `terminal.softwareUpdateAvailable` event to automate update scheduling during off-peak hours.

## You're live

> Your terminals are ready to accept real payments. For day-to-day operations, refer to [Accept a payment](/docs/payments/in-person/accept-a-payment) for the payment session flow, and [Reconciliation](/docs/operations/reconciliation) for end-of-day settlement and reporting.

## Next steps

[Accept a payment](/docs/payments/in-person/accept-a-payment) — Create a terminal payment session, present it to the terminal, and verify the result via webhook.

[Terminal management](/docs/payments/in-person/terminal-management) — Assign terminals to locations, monitor device health, and handle remote reboot or deactivation.

[Reconciliation](/docs/operations/reconciliation) — End-of-day settlement reports, payout netting, and the full reconciliation export schema.