Sell VTU / bills on your website: SprintPay → VTpass

This project (production): app and API live at https://web.sprintpay.online/ — REST API base https://web.sprintpay.online/api. Help hub: Support — Sprintpay.

If you want customers on your own website to buy airtime, data, cable, electricity, the model is:

Your website  →  SprintPay (this API & merchant wallet)  →  VTpass (telco / DISCO / pay-TV fulfilment)

SprintPay (this deployment, e.g. web.sprintpay.online) exposes the HTTP APIs and debits the merchant’s wallet on each vend. VTpass is the upstream bill-payment rail SprintPay calls server-side—you do not put VTpass keys on your own site.

This document explains that flow for webkey merchants reselling from another domain.

Webkey merchants (resellers on other sites)

If you have a webkey on SprintPay, your resale stack looks like this:

The /api/merchant/vas/* routes are the correct integration for “sell on my site, fulfil through SprintPay → VTpass.” They are documented in API.md § VTpass / VAS (webkey + SprintPay webhook token as Bearer, not the public key alone).

Appendix A in this file is the same merchant VAS path, spelled out with examples—not a separate product.

1. Who does what

2. What you implement on your side (external website → this SprintPay API)

1. Create a SprintPay account and add a webkey (Settings). Copy:
   • Public key — sent as key in JSON/query/X-Api-Key.
   • SprintPay webhook token — same secret you use for POST /api/webhooks/sprintpay; send as Authorization: Bearer <token> (or X-SprintPay-Token, etc.). Never ship this in frontend JavaScript.
2. Ensure the linked SprintPay user is verified (status = 2, not blocked) — same rules as logged-in VAS in the app.
3. Fund the wallet tied to that webkey (virtual account, pay link, or webhook settlement) so vends can debit main_wallet.
4. From your backend only, call:
   • Public catalog GETs (bundles, DISCO variations, etc.) to build your UI.
   • Merchant VAS endpoints to purchase — see API.md.
5. Handle JSON responses from each vend (success / failure / refunds where implemented) and show electricity tokens or receipts to the customer.

Extra reading (payments, VA, OpenAPI):

• API.md — payments, virtual accounts, full VTpass/VAS table.
• SPRINTPAY_WEBHOOK.md — crediting wallets from another system.
• SprintPay Readme / Support — broader product docs; VTU vend on this stack is the merchant/vas section above.

You do not integrate VTpass directly for this model; your contract is with SprintPay (web.sprintpay.online).

3. Typical request flow (this codebase)

1. (Optional) Your backend checks the merchant’s available balance on SprintPay (however you expose it internally) before checkout.
2. Customer picks product (e.g. MTN ₦500 airtime) on your site; you loaded bundles from GET /api/get-data-variations?network=mtn (or equivalent).
3. Your backend POSTs to https://web.sprintpay.online/api/merchant/vas/buy-ng-airtime (or buy-data, buy-cable, buy-electricity) with key + Bearer webhook token + body fields (phone, amount, service_id, …) — same shapes as [API.md](./API.md).
4. SprintPay authenticates the webkey + secret, debits the linked user’s wallet, calls VTpass upstream.
5. Response is JSON success/failure (and e.g. electricity token fields when applicable).
6. You show the result to the customer.
7. Separately, payment/VA webhooks to **your** fund URL fire when customers top up — that is wallet funding, not the VTpass vend callback (unless you add your own app logic).

Exact paths and sample bodies: API.md and Appendix A below.

4. If your backend is this EnkPay (Laravel) app

Some teams run EnkPay as their own server and still sell through SprintPay to end users. Then:

A) Money movement into EnkPay

When SprintPay (or your payment flow) needs to credit the EnkPay merchant wallet, use the EnkPay webhook:

• Endpoint: POST https://web.sprintpay.online/api/webhooks/sprintpay
• Auth & payload: SPRINTPAY_WEBHOOK.md
• Include your webkey (key in JSON) so EnkPay knows which merchant to credit.
• Use the same SprintPay webhook token you store in Settings → Webkeys (or global SPRINTPAY_WEBHOOK_SECRET).

That webhook does not replace SprintPay’s VTU API—it only tops up or settles the EnkPay wallet when your SprintPay integration sends the right payload.

B) Optional: EnkPay as direct VTpass proxy (advanced)

If you intentionally bypass SprintPay’s public API and want your EnkPay server to hit VTpass directly (same VTU stack EnkPay already uses), see Appendix A below. That path is for operators who control EnkPay and accept direct integration cost/complexity.

5. Security checklist

6. Summary

Appendix A — Merchant VTU HTTP API (your site → SprintPay → VTpass)

This is the standard path for reselling from any backend you control (WordPress, Node, another Laravel app, etc.). SprintPay is web.sprintpay.online; you are not calling VTpass yourself.

• Base URL: https://web.sprintpay.online/api
• Auth:
  • key — webkey in JSON body, query, or X-Api-Key.
  • SprintPay webhook secret — Authorization: Bearer <secret> or X-SprintPay-Token / X-Webhook-Secret / X-Auth-Token (same value as POST /api/webhooks/sprintpay). Not the public webkey.
    Full detail: API.md § VTpass / VAS.

Purchase / validate routes:

Public catalog (no auth): e.g. GET /api/get-data, GET /api/get-data-variations?network=mtn, GET /api/cable-plan, GET /api/get-electricity-variations?serviceID=ikeja-electric, etc.

Minimal cURL (Nigeria airtime):

curl -sS -X POST 'https://web.sprintpay.online/api/merchant/vas/buy-ng-airtime' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_SPRINTPAY_WEBHOOK_SECRET' \
  -d '{"key":"YOUR_WEBKEY","service_id":"mtn","amount":500,"phone":"08012345678"}'

OAuth alternative (dashboard / mobile app users): POST /api/auth then POST /api/buy-ng-airtime, buy-data, buy-cable, buy-electricity with Passport token — same VTpass backend, different auth.

Appendix B — Related EnkPay docs