AbaPay -- non-custodial stablecoin bill-payment rails for agents on Celo

Ecosystem Dapps
1

What it is: AbaPay settles real-world bills – airtime, mobile data, electricity, cable, education (WAEC/JAMB), bank transfers – in Celo stablecoins (USDC, USD₮, USA₮), non-custodially, with delivery handled through VTpass (a licensed Nigerian bill-aggregation API) on confirmed on-chain settlement. Outside Nigeria it also reaches 144 countries for airtime/data top-ups via VTpass’s live international catalogue.

The site at agents.abapays.com is the Celo-only, agent-first front door – built specifically so an autonomous agent can settle a bill without a human clicking through a checkout flow.

Three ways to call it, all agent-native:

  • x402 – zero setup. Any wallet calls the endpoint, gets a 402 challenge, signs an EIP-3009 authorization, and settles through Celo’s own facilitator. No account, no session.
  • MCP – 10 tools over Streamable HTTP JSON-RPC (describe_capabilities, check_balance, list_plans, pay_bill, pay_bill_batch, schedule_bill, transaction_history, and more), OAuth 2.1 or API key.
  • A2A / REST – an agent card plus a plain OpenAPI 3.1 spec for POST /api/pay/x402.
    Custody & risk model: non-custodial pull-based ERC-20 allowance the payer sets themselves – never a deposit. Per-transaction cap and total allowance ceiling enforced on-chain. A failed off-chain delivery (VTpass rejection, wrong account details) triggers an automatic on-chain refund, not a support ticket.

Live, verifiable, as of 2026-09-18:

Where we could use the community’s help:

  • Feedback from anyone building agent-payment infrastructure on Celo, especially around x402 settlement patterns – we’ve run into a real gap around post-settlement recipient verification for off-chain/real-world fulfillment that we plan to raise with the x402-foundation.
  • Any agent framework or wallet builder on Celo that wants a bill-payment rail to call into – no integration work needed beyond a standard x402 or MCP client.

Happy to answer questions here or dig into specifics – full docs at docs.abapays.com.

2 Likes
2

Interesting use case. The non-custodial approach and automatic refund path seem particularly important when an on-chain payment depends on off-chain fulfillment.

Disclosure: I work in business development and support for Gem Wallet, which supports Celo. From the perspective of someone holding Celo stablecoins in a general multichain wallet, can the standard x402 payment flow be initiated from any compatible self-custody wallet, or does the current experience require agent or API tooling? That distinction may determine how accessible this is to ordinary users.

3

Good question, worth being precise about since the two halves have different answers.

Signing capability: universal. What x402 needs from the wallet is a standard EIP-3009 transferWithAuthorization signature (EIP-712 typed data) – the same signing primitive any dApp integration already uses. Any self-custody wallet on Celo can produce that signature; there is nothing AbaPay-specific about the key or the account.

Initiating the flow: not yet, without a client that speaks x402. Beyond the signature itself there are three HTTP round trips – request a price, receive the 402 challenge, retry with the signed authorization attached – and no wallet’s ordinary send screen runs that sequence on its own today. Right now something has to drive it: our abapay-sdk (npm/PyPI), a CLI, or an agent.

So for an ordinary user holding Celo stablecoins in a general wallet with no SDK or agent involved: not yet self-serve. Closing that gap means a wallet’s own UI detecting a 402 response and running the challenge/sign/retry sequence itself. Full request/response shapes are at x402 — Zero-Setup Agent Payments if that’s useful for scoping what that would take on Gem Wallet’s side.

Happy to go deeper on specifics if that’s a direction worth exploring.

4

Thanks for clarifying. The distinction between being able to sign the authorization and having a client that manages the full x402 flow is helpful.

I can share the documentation internally as product feedback, but I can’t comment on implementation plans or the roadmap. From a support perspective, clear messaging for users whose wallet does not yet handle the x402 flow would also be important.

5

Fair point, and a useful one to make concrete rather than leave abstract.

Worth separating who actually needs that messaging: anyone visiting abapays.com directly (where a human clicking through from Gem Wallet would land) never touches x402 at all – that’s a completely separate, already-guided flow (connect, see the live price, approve, sign), the same as any other supported wallet. The messaging gap only bites if a Gem Wallet user, or Gem Wallet’s own client, calls the x402 endpoint directly and hits a 402 with no automated way to finish it.

For that specific case, it’s fair feedback that the 402 response and docs should say so plainly instead of assuming every caller has a client that knows what to do with a challenge. I’ll add a short note to that effect – worth flagging back to your team once it’s live, in case it’s useful for how Gem Wallet frames “does AbaPay work with my wallet.”

6

Thanks, that distinction is helpful. Knowing that the regular abapays.com flow is already guided, while the x402 limitation only affects direct endpoint callers, will make support guidance much clearer. I’ll keep an eye out for the documentation note.

1 Like