Developers
REST API
GuidesErrorsLogin
Get API Keys
API Navigation
  • Overview
  • Quick start
  • Authentication
  • Collect a payment
  • Payment status
  • Refunds
  • Testing
  • Production
  • Security
API reference
  • Create API keys POST
  • List API keys GET
  • Get API key GET
  • Delete API key DEL
  • Collect with MTN POST
  • MTN payment status GET
  • Collect with Airtel POST
    Create and pay
  • Create order POST
  • Order fee POST
  • Pay order with card POST
  • Pay order with bank POST
  • Status and verify
  • Order status POST
  • Verify order POST
  • Cards and tokens
  • Save card POST
  • Tokenize charge GET
  • Refunds
  • Refund order POST
  • Lists and stats
  • List orders GET
  • Get order GET
  • List banks GET
  • Order stats GET
  • List transactions GET
  • Get transaction GET
  • Transaction statuses GET
Errors and limits
  1. Docs
  2. Getting started
  3. Authentication

Authentication

A comprehensive guide to authenticating requests via Merchant JWT Bearer tokens, HTTP-only session cookies, and Gateway API Keys.

Authentication Methods Comparison

Ziba Pay enforces authentication across all sensitive API routes. Depending on whether your system is an automated backend service, a scheduled worker, or a browser-based web application, select the appropriate authentication strategy below:

MethodTarget ConsumerHTTP Header / CookieSecurity CharacteristicsSupported Routes
Merchant Bearer TokenBackend servers, microservices, mobile appsAuthorization: Bearer <token>Stateless JWT, 15-min lifespan, 30-day refresh tokenAll /orders/*, /transactions/*, /developer/*, and merchant /payment/*
Gateway API KeysDirect server-to-server payment automationx-api-key and x-api-secretOne-way hashed secret, persistent until revokedPOST/payment/mtn-momo-pay, GET/developer/gatewayConfigs/:apiKey
Cookie-Based SessionBrowser web apps, client dashboardsCookie: auth_token=<token>HTTP-only; requires X-Requested-With: XMLHttpRequest for CSRF protectionAll dashboard mutation routes

Bearer Token Authentication (JWT)

Merchant routes authenticate using a signed JSON Web Token (JWT) passed in the standard Authorization HTTP request header:

Node.js (Axios) — Bearer Token Request
import axios from "axios";

const response = await axios.get("https://payment-service-mh2d.onrender.com/api/transactions", {
  headers: {
    Authorization: `Bearer ${process.env.ZIBA_TOKEN}`,
    "Content-Type": "application/json",
  },
  timeout: 10000,
});

console.log("Transactions:", response.data);

Gateway API Keys (Server-to-Server)

Automated payment jobs that do not maintain short-lived merchant login sessions authenticate using Gateway API Keys (x-api-key and x-api-secret).

You generate API Keys via POST/developer/gatewayConfigs. The plaintext apiSecret is shown only once and must be stored securely in an environment variable.

cURL — Gateway API Key Request
curl -X POST "https://payment-service-mh2d.onrender.com/api/payment/mtn-momo-pay" \
  -H "Authorization: Bearer $ZIBA_ACCESS_TOKEN" \
  -H "x-api-secret: $ZIBA_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 100,
    "currency": "RWF",
    "phoneNumber": "+250788000000"
  }'

Token Lifecycles & Automatic Refresh

When you authenticate via POST/auth/login or POST/auth/signup, Ziba Pay returns both an access token and a refresh token in the response JSON and sets corresponding HTTP-only cookies:

Token TypeStorage LocationLifespanRenewal Method
Access Token (token)In-memory / auth_token cookie15 minutesExchange refresh token via POST/auth/refresh
Refresh Token (refreshToken)Encrypted vault / refresh_token cookie30 daysRe-authenticate with POST/auth/login
Gateway API SecretServer environment variablesPersistent until revokedRevoke via DELETE/developer/delete/:id and re-create

CSRF Defense for Browser Cookie Sessions

Direct server-to-server calls authenticated via Bearer tokens or Gateway API Keys do not require CSRF headers.

However, if you invoke mutation endpoints (POST, PATCH, DELETE) from a web browser using cookie-based authentication, you must send the header below to prevent Cross-Site Request Forgery:

CSRF Protection Header
Browser cookie mutations without 'X-Requested-With: XMLHttpRequest' are rejected immediately with HTTP 403 { status: 'fail', message: 'This request must include the X-Requested-With header' }.

Account & Authentication Endpoints

The table below details all identity, session, and credential lifecycle routes:

EndpointMethodAuth RequiredDescription
/auth/signupPOSTNoneRegister a new merchant account; returns JWT token pair.
/auth/loginPOSTNoneSign in with email and password. Every role is emailed a 6-digit code; no session is issued yet.
/auth/verify-otpPOSTNoneVerify the 6-digit email OTP and receive the JWT token pair.
/auth/refreshPOSTRefresh TokenExchange valid refresh token for a fresh 15-min access token.
/auth/logoutPOSTBearer / CookieRevoke active merchant sessions and clear session cookies.
/auth/forgot-passwordPOSTNoneRequest a password reset email.
/auth/reset-password/:tokenPATCHNoneSet a new password using reset token.

Fields

FieldTypeRequiredDescription
firstNamestringRequiredSignup only. Merchant first name. Minimum 2 characters.
lastNamestringRequiredSignup only. Merchant last name. Minimum 2 characters.
emailstringRequiredSignup and login. Valid email address.
passwordstringRequiredSignup (min 8 characters) and login.
howHearstringRequiredSignup only. Referral source.
businessNamestringRequiredSignup only. Registered business or store name.
businessTypestringRequiredSignup only. Business industry or entity type.
countrystringRequiredSignup only. Business operating country.
phoneNumberstringRequiredSignup only. Valid phone number with international dial code.
otpCodestringRequiredPOST /auth/verify-otp, with email, after any role signs in.
refreshTokenstringOptionalPOST /auth/refresh. Also accepted from the refresh_token cookie or x-refresh-token header.

Notes

  • POST /auth/signup and POST /auth/register invoke the identical registration handler. HTTP 201 returns the token pair.
  • POST /auth/login returns { status: 'success', message: 'OTP sent to your email' } for every role. POST /auth/verify-otp then returns the token pair.
  • POST /auth/login, POST /auth/verify-otp, and POST /auth/refresh are rate-limited to 10 requests per 15 minutes from a single IP.
  • POST /auth/refresh replaces both access and refresh cookies. POST /auth/logout clears both cookies.

Related

Quick startCreate API keysCollect with MTN
Was this page helpful?

Let us know how we can make our API documentation better.

PreviousQuick start
NextCollect a payment