> ## Documentation Index
> Fetch the complete documentation index at: https://docs.choosefloat.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing & go-live

> How to test your integration in the sandbox, and the checklist to pass before switching to production.

## The sandbox

All integration testing happens against the UAT environment:

```
https://uat-secure.choosefloat.com
```

It's a full replica of production wired to the payment gateway's test environment — no real money moves. Use your **sandbox client secret and signing key** (they are different credentials from production).

### Test payments

On the sandbox payment page, use gateway test cards (your Float contact will supply the current set, including cards that trigger 3-D Secure challenges and declines). Walk through at minimum:

* a successful payment on each instalment term you support,
* a shopper cancel (click cancel on the payment page → expect a `cancelled` callback),
* a declined card followed by a successful retry (expect a single `successful` callback — no notification for the decline),
* an abandoned session (close the browser → checkout stays `received`).

### Testing callbacks locally

Expose your development server with a tunnel (ngrok, Cloudflare Tunnel) and pass the tunnel URL as `notify_url`, or [simulate deliveries with curl](/guides/callbacks#testing-your-handler-locally).

## Go-live checklist

<Steps>
  <Step title="Callback handling is correct">
    * `X-Signature` verified on every callback, constant-time comparison, raw-body based.
    * Handler is idempotent — duplicate deliveries cause no double-fulfilment.
    * Responds `2xx` in under 10 seconds; slow work is deferred.
    * Fulfilment keys off the callback (or a `GET /api/checkouts/:id` check), never off `success_url` traffic.
  </Step>

  <Step title="Request signing is enabled">
    You're sending a valid `X-Signature` on `POST /api/checkouts` and `POST /api/refunds`. Remember [signing is sticky](/authentication#request-signing) — once Float sees a signed request, unsigned mutations are rejected.
  </Step>

  <Step title="Amounts are correct">
    * All amounts are integer **pence**.
    * The checkout `amount` equals what you'll fulfil for — server-side calculated, never trusted from the browser.
    * Currency matches your merchant territory (`GBP`).
  </Step>

  <Step title="Edge cases are covered">
    * Cancelled callbacks release stock/orders.
    * Stale `received` checkouts are treated as abandoned and reconciled.
    * The `success_url` page tolerates a not-yet-confirmed order (pending state, not an error).
  </Step>

  <Step title="Refunds work end-to-end">
    Create a partial and a full refund in sandbox and track them to `complete`. Confirm your admin tooling surfaces the refund-window errors (100-day limit, same-day rule on auto-refund integrations) sensibly.
  </Step>

  <Step title="Production configuration">
    * Production client secret and signing key installed via your secret manager.
    * Base URL switched to `https://secure.choosefloat.com`.
    * `notify_url` points at your production endpoint with a valid TLS certificate.
    * Rate limits respected (see [API overview](/api-reference/overview#rate-limits)) — in particular, merchant config is cached, not fetched per page view.
  </Step>

  <Step title="Run one live smoke test">
    Make a small real purchase, confirm the callback, fulfilment, and settlement reporting, then refund it (on auto-refund integrations, the refund can only be created after 10:00 the next day).
  </Step>
</Steps>

## Support

* Integration questions: [support@float.co.za](mailto:support@float.co.za)
* Include your merchant name, the environment, the checkout `id`, and timestamps with any issue report — Float logs every API request and callback delivery and can trace a payment end to end.