Everything below is real, working API behavior. Amounts are always in minor
units (for example,
10000 = £100.00 / ₦100.00). Timestamps are RFC 3339
unless a field is explicitly described as a Unix timestamp.Base URLs
| Environment | Base URL |
|---|---|
| Production | https://api.faira.io |
| Sandbox / Staging | https://api.staging.faira.io |
| Local development | http://localhost:8080 |
/api/v1. Replace the host with the
environment you are integrating against.
Use the exact host issued to your account. If you are unsure which environment
your credentials belong to, contact your Faira representative before going live.
Credentials & tokens at a glance
Faira issues several distinct secrets. They are not interchangeable — each is used for a specific purpose.| Credential | Prefix | Where it is used | Lifetime |
|---|---|---|---|
| API key | fai_live_mk_ | Identifies your account. Sent as the X-Api-Key header (HMAC flow) or as a Bearer token for read-only dashboard endpoints. | Until rotated |
| API secret | fai_secret_ | Signs HMAC requests (X-Signature). Shown once at registration/rotation. Never sent over the wire. | Until rotated |
| Webhook signing secret | fai_whsec_ | Verifies webhooks Faira sends you, and signs payment events you send Faira. | Until rotated |
| Dashboard session token | fai_mst_ | Returned by login. Authorizes sensitive dashboard actions. | 8 hours (default) |
| Relationship access token | fai_at_ | Short-lived token that authorizes a customer’s limit/transaction calls. | ~15 minutes |
Step 1 — Create your merchant account
There are two ways an account is created. Most self-serve integrations use registration; enterprise accounts are provisioned by the Faira team.- Self-service registration
- Admin-provisioned account
Register directly and receive live credentials immediately. The account is created
in Failure responses
active status — you can log in and integrate right away.Registered business / trading name. Must be unique across Faira.
Primary contact’s full name.
Valid email. This becomes your dashboard login and receives the welcome email.
E.164 format, e.g.
+447700900000.One of
limited_company, sole_trader, partnership, other.ISO 3166-1 alpha-2 country code, e.g.
GB or NG.Optional business website (must be a valid URL).
Optional. HTTPS endpoint that will receive webhook deliveries. You can set this at
registration or add it later via your profile.
See Webhook URL requirements.
Minimum 8 characters. Used for dashboard login.
Must match
password.Request
201 Created
| Status | Code | Meaning |
|---|---|---|
400 | invalid_json | Body is not valid JSON |
409 | registration_failed | An organization with that name already exists |
422 | passwords_do_not_match | Password and confirmation differ |
422 | registration_failed | A required field failed validation |
Step 2 — Log in to the dashboard
Exchange your email and password for a dashboard session token (fai_mst_).
The session is required for sensitive actions such as rotating credentials.
Request
200 OK
Forgot / reset password
Forgot / reset password
Request a reset link. The response is always Then apply the emailed token (valid for 1 hour):
200 to prevent email enumeration —
a link is only sent if the email exists.Step 3 — Complete your profile
Fill in the fields Faira needs to route payments and settle funds to you. Send the API key or a dashboard session on these endpoints.PATCH body
200 OK
organization_name, business_type, country, and status are locked after
registration and cannot be changed here. Contact support if any of these need to
change.Step 4 — Store & rotate credentials
Rotating credentials revokes your current API key and secret and issues a new pair. This requires an active dashboard session — API-key auth is intentionally rejected here so a leaked key cannot rotate itself.200 OK
Authenticating your requests
Faira supports three auth styles depending on the endpoint:API key (bearer)
Read-only dashboard endpoints. Send
Authorization: Bearer fai_live_mk_....Dashboard session
Sensitive dashboard actions. Send
Authorization: Bearer fai_mst_....HMAC signing
Server-to-server checkout endpoints. Sign the request with your API secret.
HMAC request signing
Checkout endpoints (POST /api/v1/sessions/initiate, POST /api/v1/sessions/token)
require a signed request. Send these headers:
| Header | Value |
|---|---|
X-Merchant-Id | Your merchant UUID |
X-Api-Key | Your fai_live_mk_ API key |
X-Timestamp | Current time in RFC 3339 (e.g. 2026-07-13T12:00:00Z) |
X-Nonce | A unique, single-use string per request |
X-Signature | Lowercase hex HMAC-SHA256 (see below) |
\n (newline), in this exact order:
HMAC-SHA256(api_secret, string-to-sign), hex-encoded and
lowercase. The raw-json-body must be the exact bytes you send — sign the
serialized body, then send that same body unchanged.
Checkout session flow
Once authenticated, you initiate a checkout session for a customer. This creates a pending transaction and returns a redirect URL that takes your customer into Faira’s hosted login/onboarding flow.Initiate the session
POST /api/v1/sessions/initiate (HMAC-signed). Include the transaction and,
for returning customers, their customer_token.Request
201 Created
Redirect the customer
Send the customer’s browser to the returned
redirect_url. They log in or
onboard with Faira, which resolves the pending transaction from session_id.customer_token, unique_customer_reference, and redirect_url are all optional.
Faira returns a customer_token for a customer only after their relationship with
you is verified — store it and send it on future checkouts for a smoother returning
experience. The full journey (references, tokens, mappings, transaction
authorization) is covered in the Checkout Sessions guide.Step 5 — Configure webhooks
Faira notifies your backend of transaction state changes byPOSTing a signed JSON
payload to your webhook_url. Set the URL when you
register (optional webhook_url field) or
later via your profile. Webhooks are only delivered
once a webhook_url is configured.
Webhook URL requirements
Must be HTTPS.
Must not be localhost, a private/internal IP, or a blocked consumer domain.
Should respond with a
2xx quickly (Faira’s delivery timeout is 10 seconds).Events
| Event | When it fires |
|---|---|
transaction.authorized | Customer authorized the transaction |
transaction.declined | Customer declined the transaction |
transaction.paid | Checkout transaction was paid (card or SteadyPay) |
transaction.paid_out | Merchant payout completed (reserved — not yet emitted) |
Delivery headers
Every delivery includes:Example payload
Some fields appear only when available. Legacy authorization/decline deliveries may
omit
provider and payment_transaction_id.Verifying the signature
The signature isHMAC-SHA256 of timestamp + "." + raw_body, using your
webhook signing secret (fai_whsec_...), prefixed with sha256=.
Retries & delivery
Faira treats any2xx as delivered. Non-2xx responses, network errors, and
timeouts are retried with exponential backoff:
| Attempt | Delay before retry |
|---|---|
| 1 | 1 minute |
| 2 | 2 minutes |
| 3 | 4 minutes |
| 4 | 8 minutes |
| 5 | 16 minutes |
queued → processing → delivered, or retrying → failed once the
retry limit is reached.
Inspect your webhook deliveries
You can review the outbound webhooks Faira has sent you — useful for debugging a missed or failing delivery. These endpoints require a dashboard session (fai_mst_...).
| Param | Description |
|---|---|
status | Filter by delivery status (queued, processing, delivered, retrying, failed) |
event | Filter by event name (e.g. transaction.paid) |
page | Page number (default 1) |
per_page | Items per page (default 25) |
200 OK — list
{ "webhook": { ... } }. Use
status, attempts, and last_error to diagnose failures.
Inbound payment events (optional)
If you settle payments yourself, you can notify Faira of payment/payout events with a signed request to:timestamp.raw_json_body using your webhook signing secret —
the same algorithm Faira uses for outbound deliveries.
Request
202 Accepted
transaction_id (Faira’s ID) or merchant_ref (your reference).
Events are deduplicated by event_id; a duplicate returns 202 with
"duplicate": true. Accepted event names: payment.paid / transaction.paid /
paid, and payment.paid_out / payout.paid_out / paid_out / settled.
Error handling
Errors use a consistent JSON envelope:| Status | Typical cause |
|---|---|
400 | Malformed JSON or invalid parameters |
401 | Missing/invalid credentials, bad HMAC signature, or expired session |
404 | Resource not found |
409 | Conflict (e.g. duplicate organization name) |
422 | Validation error (e.g. passwords don’t match) |
429 | Rate limited (registration, login, and password endpoints are throttled) |
Go-live checklist
Credentials stored securely
API key, API secret, and webhook signing secret are in your secrets manager —
not in source control.
Webhook endpoint live
HTTPS, publicly reachable, verifies signatures, is idempotent, and replies
2xx within 10 seconds.merchant_id (never share your API secret or webhook signing secret).