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

# Going Live

> Pre-launch checklist for moving your PalPluss integration to production.

# Going Live

Ship with confidence. Run through this checklist before accepting live payments.

***

## Pre-launch checklist

<AccordionGroup>
  <Accordion title="Account setup">
    * [ ] KYC submitted and approved (required for B2C payouts)
    * [ ] Live API key generated from the console
    * [ ] Service wallet funded with enough balance for expected volume
    * [ ] Payment channels (Paybill/Till) configured and verified
  </Accordion>

  <Accordion title="Integration">
    * [ ] Webhook endpoint deployed and accessible over HTTPS
    * [ ] Webhook handler returns `200` before processing (async)
    * [ ] Duplicate callback delivery handled (idempotent processing)
    * [ ] All terminal states handled: `SUCCESS`, `FAILED`, `CANCELLED`, `REVERSED`
    * [ ] `requestId` logged from every API response
  </Accordion>

  <Accordion title="Error handling">
    * [ ] `402 INSUFFICIENT_SERVICE_BALANCE` handled — alerts your team to top up
    * [ ] `429` rate limit handled with `Retry-After` backoff
    * [ ] `500` server errors retried with exponential backoff
    * [ ] Payment failures communicated gracefully to end users
  </Accordion>

  <Accordion title="Security">
    * [ ] API key stored in environment variables — not in source code
    * [ ] API key not exposed in client-side code or mobile binaries
    * [ ] HTTPS enforced on webhook endpoints
    * [ ] Webhook payloads validated against your transaction records
  </Accordion>

  <Accordion title="Operations">
    * [ ] Alerts configured for payment failures above expected threshold
    * [ ] Service wallet balance monitored — alert before balance runs out
    * [ ] Process documented for manually confirming transactions if webhooks are missed
    * [ ] Support contact available for live payment issues
  </Accordion>
</AccordionGroup>

***

## Service wallet

The service wallet holds pre-funded balance used to pay transaction fees. Every STK Push and B2C payout deducts a fee at initiation.

**If balance reaches zero**, new payment requests return `402 INSUFFICIENT_SERVICE_BALANCE`. No payments can be processed until you top up.

**Recommended:**

* Set an alert threshold (e.g. KES 500) and top up proactively
* Top up via `POST /wallets/service/topups`
* Monitor `GET /wallets/service/balance` in your operations dashboard

***

## B2C payouts — KYC requirement

B2C payouts require approved KYC. Initiating before approval returns `403 KYC_NOT_VERIFIED`.

1. Submit documents from [console.palpluss.com](https://console.palpluss.com) under **KYC**
2. PalPluss reviews within 1–3 business days
3. B2C payouts are enabled automatically on approval

***

## Phone number formats

The API accepts multiple formats and normalises them internally:

| Input           | Normalised     |
| --------------- | -------------- |
| `0712345678`    | `254712345678` |
| `0112345678`    | `254112345678` |
| `+254712345678` | `254712345678` |
| `254712345678`  | `254712345678` |

Pass clean numbers — no spaces, dashes, or parentheses.

***

## STK abuse protection

PalPluss monitors STK Push patterns. Accounts with unusually high failure rates or low success ratios may be temporarily suspended.

This does not trigger under normal usage. For bulk use cases, contact [developer@palpluss.com](mailto:developer@palpluss.com) before launch.

***

## Rate limits

**60 requests per minute per API key.** Sufficient for most integrations.

To increase throughput:

* Use separate API keys for distinct services or payment flows
* Contact support to discuss custom limits for high-volume use cases

***

## Test before scaling

PalPluss does not provide a sandbox. Test with small real amounts (KES 1) before processing larger transactions.

<Tip>
  Initiate a KES 1 STK Push, confirm on a test phone, and verify your system fulfils the order end-to-end — then scale up.
</Tip>