# Production Go-Live Guide

This is a step-by-step guide for deploying your Flute payment integration to Production.
It is required to move your Flute integration from the sandbox environment to the production environment.
You must receive a sign-off from your Flute integration contact.
It covers readiness checks, security, credentials, go-live testing, monitoring, and post-launch optimization.
We recommend working through each section in order.
Skipping steps increases the risk of issues after launch.

## Production Readiness Checklist

Use this checklist to confirm your integration is ready before requesting Production access.

### Integration Completeness

| Checklist Item | Notes |
|  --- | --- |
| *-*All payment flows tested end-to-end in the sandbox environment.** | Including success, decline, and edge cases. See the Testing Scenarios Guide. |
| **Refund and void flows tested** | Both full and partial refund scenarios. |
| **Token refresh logic implemented** | Tokens must never expire mid-session for end users. |
| **Idempotency keys used on all mutating requests** | Prevents duplicate charges on network retries. |
| **Error handling covers all documented error codes** | User-facing messages must not expose raw error codes or stack traces. |
| **Load testing completed** | Coordinate with Flute before running load tests. See the Testing Scenarios Guide. |


### Code and Infrastructure

| Checklist Item | Notes |
|  --- | --- |
| **Production credentials stored in a secrets manager** | Not in code, .env files committed to version control, or CI/CD logs. |
| **All sandbox URLs replaced with Production URLs** | Search your codebase for "sandbox.api.flute.com," and replace with "api.flute.com". |
| **Logging excludes card information, CVVs, and full PANs** | Log transaction IDs and error codes only. |
| **HTTPS enforced on all endpoints that touch payment data** | No mixed-content or HTTP fallbacks. |
| **Timeout and retry policies configured** | Recommended: 30s timeout, 3 retries with exponential backoff. |


## Security Review and Compliance Checks

### PCI-DSS Compliance

Flute's payment solutions are designed to keep your integration out of PCI-DSS scope for card data. Confirm the following before launch:

- Card numbers, CVVs, and expiry dates are never transmitted through your servers.
- POS Integration: Your point-of-sale system uses Flute's certified card readers that handle card data securely and never expose it to your application layer.
- Flute Elements: The frontend loads Flute Elements through the official script tag.
- Do not self-host or bundle it.


Contact your Flute integration contact to receive Flute's current PCI-DSS attestation documents if required by your compliance team.

If you are building a server-to-server integration that handles raw card data directly, a full PCI-DSS assessment is required. Consult your Flute account team for guidance on the appropriate compliance path.

## Production Credentials and Configuration

### Environment Configuration

Keep the sandbox and production environments configurations strictly separated.
Use environment-specific configuration files and never share credentials between environments.

```bash
# .env.production (never commit this file)
FLUTE_CLIENT_ID=prod_client_id_here
FLUTE_CLIENT_SECRET=prod_client_secret_here
FLUTE_OAUTH_BASE_URL=https://oauth.api.flute.com
FLUTE_BASE_URL=https://api.flute.com
```

```bash
# .env.sandbox (never commit this file)
FLUTE_CLIENT_ID=sandbox_client_id_here
FLUTE_CLIENT_SECRET=sandbox_client_secret_here
FLUTE_OAUTH_BASE_URL=https://sandbox.oauth.api.flute.com
FLUTE_BASE_URL=https://sandbox.api.flute.com
```

### Flute Elements in Production

Update the Flute Elements script tag to load from the Production URL:

```html
<!-- Production -->
<script src="https://public.flute.com/lib/v1.0/flute.mjs" type="module"></script>
```

### Go-Live Guide

The following sections detail the ISV and merchant integrators' certification procedures.
It also allowing Flute to track metrics of each.
Follow the steps for the respective group.

#### ISV Certification

The following is for ISV (integrated software vendors).

**Certification Requirements**

ISVs must:

- Work directly with their assigned Flute integration specialist.
- Provide a list of implemented API endpoints.
- Execute required test cases specific to their integration endpoints.
- Validate all required transaction flows, such as auth, sale, capture, refund, and void.
- Complete any required PCI validation if not using Flute hosted solutions.


**Test Case Execution**

- Test cases are defined by Flute based on the ISV’s integration scope.
- All validation must be completed in the sandbox environment.
- Results must be reviewed and approved by a Flute integration specialist.


#### Merchant Certification

The following is for Merchant (Individual Merchant Integrators).
There are two options for certification

- Self Certification
- Certification Requested.


**Self Certification** 
Merchants who are confident in their work can directly go live with their production account credentials.

**Certification Requested** 
Merchants can request that the Flute Integrations team reviews the integrated development work.
Merchant certification focuses on confirming proper API usage, transaction processing, and dashboard visibility prior to go-live.
The Flute Integrations team will provide next steps.
Contact:

- developer@flute.com.


### Go-Live Approval

Go-Live Approval
Before announcing launch to end users:

**ISVs**: A certification letter will be provided by the Flute Integrations team to the ISV prior to production enablement.

**Merchant Requested Certification**.
Merchants will be provided approval notification after Flute confirms integration is properly implemented.
Production credentials should not be used until certification approval has been granted.

## Monitoring and Alerting Setup

### Key Metrics to Monitor

Set up dashboards and alerts for the following before go-live:

| Metric | Alert Threshold | Severity |
|  --- | --- | --- |
| **Payment success rate** | < 95% over 5 minutes | Critical |
| **Payment API P95 latency** | > 3 seconds | Warning |
| **Token refresh failure rate** | Any failure | Critical |
| **Rate limit (429) responses** | > 5 in 1 minute | Warning |
| **API 5xx error rate** | > 1% over 5 minutes | Critical |


### What to Log

Log enough information to reconstruct any failed transaction without storing sensitive card data:

```js
// Good — enough context to investigate, no sensitive data
logger.info('Payment session created', {
  sessionId: session.sessionId,
  merchantId: config.merchantId,
  amount: session.amount,
  currency: session.currency,
  correlationId: req.headers['x-arise-trace-correlationid'],
});

logger.error('Payment declined', {
  sessionId: session.sessionId,
  errorCode: response.errorCode,
  httpStatus: response.status,
  correlationId: req.headers['x-arise-trace-correlationid'],
});

// Bad — never log these
logger.info('Card submitted', {
  cardNumber: '4111111111111111', // ❌ PCI violation
  cvv: '123',                     // ❌ PCI violation
});
```

## Support Channels

### Contact Directory

| Scenario | Contact | Channel |
|  --- | --- | --- |
| **Pre-launch integration questions** | Flute Integration Team | developer@flute.com |
| **Production outage or critical issue** | Flute Support | techsupport@flute.com — mark subject URGENT |
| **Other questions or requests** | Flute Support | developer@flute.com |


### What to Include in a Support Request

Provide the following information when contacting Flute support to minimize back-and-forth:

1. **Merchant ID** — found in the Merchant dashboard under Settings.
2. **Transaction ID or Session ID** — the specific resource that failed.
3. **Timestamp** — the exact time the issue occurred (include timezone).
4. **Request and response details** — headers, status codes, and error codes (never include card data).
5. **Steps to reproduce** — what actions trigger the issue.
6. **Impact** — how many users or transactions are affected.