i4pay API
Accept payments from your website, app or portal in three calls. All amounts are integers in kobo (₦1,500.00 = 150000).
Authentication
Send your secret key in the Authorization header. Keys starting sk_test_ use the sandbox (no real money); sk_live_ keys move real money and are issued once your business is approved. Never put a secret key in a browser or mobile app.
Base URL: https://i4pay.i4datanation.com.ng/api/v1 · Every response is {"status": true|false, "message": "...", "data": ...}.
1. Initialize a payment
POST /transactions/initialize — returns a checkout_url. Redirect your customer there.
| Field | Required | Notes |
|---|---|---|
amount | Yes | Kobo, whole number. Send the clean amount you want to receive — do not add your own gateway or convenience charges, because i4pay adds its charge on top at checkout and your customer would pay twice. |
channel | No | card, transfer or ussd to fix the payment method. Leave it out and the customer chooses on i4pay's checkout, where each method shows its exact total (bank transfer has the lowest fee). |
email | Yes | Customer's email (receipt goes here). |
reference | Recommended | Your unique order reference. Re-using a pending reference returns the same payment. |
callback_url | No | Where we send the customer afterwards, with ?reference=…&status=…. Defaults to the URL in your dashboard. |
fee_bearer | No | Leave it out and the customer pays the charge: it is added on top at checkout and you receive the full amount. Send merchant to absorb the fee yourself (deducted from your settlement) where your account allows it. |
customer_name, customer_phone, description, metadata | No | Stored and returned with the transaction and webhooks. |
Until the customer picks a method, fee and charged show the highest (card) price. The final figures are in the verify response and webhooks.
2. Verify the payment
GET /transactions/verify/{reference} — always verify on your server before giving value. Give value only when data.status is success and data.amount matches your order.
Statuses: pending, success, failed, abandoned, reversed.
3. Webhooks
Set your webhook URL under API keys & webhooks. We POST JSON events: charge.success, charge.failed, refund.processed. Verify the signature, answer with HTTP 200 quickly, then process. We retry failed deliveries with back-off for about two days.
Other endpoints
| Method | Path | What it does |
|---|---|---|
| GET | /transactions | List payments. Filters: status, from, to (YYYY-MM-DD), page, per_page. |
| GET | /transactions/{reference} | One payment (no gateway re-check). |
| GET | /fees?amount=4500000 | Fee quote before you charge: what the customer will pay and what you will receive. |
| POST | /refunds | {"reference": "...", "amount": 100000, "reason": "..."} — reviewed by our finance team. |
| GET | /balance | What we owe you, reserves and payments awaiting settlement. |
| GET | /settlements | Your settlement history. |
| GET | /banks | Bank names and codes. |
Good practice
- Send an
Idempotency-Keyheader on initialize so a retried request never creates two payments. - Rate limit: 120 requests per minute per key (HTTP 429 when exceeded).
- Test cards and transfer simulation are provided by Monnify's sandbox when you use test keys.