The Interledger Community 🌱: Temidayo Jacob

OpenCheckout: A Thought Experiment

Temidayo Jacob — Wed, 17 Jun 2026 13:00:00 +0000

When you want to accept payments online today, the playbook is the same: sign up for Stripe, copy a few lines of code, and you are done. In Nigeria, we mostly use Paystack or Flutterwave. It works. But it also means you are paying a certain percentage on every transaction, your payment data lives on someone else's servers, and your customers need a credit card.

For a lot of businesses, that is fine. For a lot of others — especially developers, small merchants, and communities that care about freedom — it is a compromise they never really chose. It was just the only option.

I wanted to know if there was another way. That question led me to experimenting and building OpenCheckout using Open Payments.

The Problem With How We Accept Payments

Traditional payment checkout products are excellent. They abstract away enormous complexity. But that abstraction comes at a cost you feel every single month from per-transaction fees, data, and a checkout experience you cannot fully control.

More fundamentally, these platforms sit between you and your customer's money. They are not just processing payments, but instead, they are the entire payment relationship. If Stripe decides to hold your funds, change their pricing, or deprecate an API, you adapt or you leave. There is no self-hosting option. There is no alternative provider you can swap in without rewriting your integration.

I started asking, "What would a checkout system look like if it were built like an open protocol that any merchant can implement, where you can choose your host, and where the software is yours?"

Looking At Open Payments

Around this time last year I did something similar for CTRL+Pay, but this time I did some proper research into Open Payments. I like that Open Payment defines a way for applications to issue payment instructions to account servicing entities without touching funds. I also like how it is designed for interoperability.

So, I read through the documentation and the SDKs word for word. The more I understood it, the more it felt like the missing piece. What was missing was the checkout layer — the thing that makes Open Payments usable for a merchant who just wants to sell a product globally.

OpenCheckout

OpenCheckout is a self-hosted checkout system. You deploy it on your own server with a single docker compose up command. It gives you a REST API for creating checkout sessions and a hosted payment page where your customers enter their wallet address to pay.

Under the hood, OpenCheckout orchestrates the full Open Payments flow: it creates an incoming payment on your wallet, requests a quote from your customer's account provider to confirm the cost, facilitates the interactive grant where your customer approves the payment at their own bank, and issues the outgoing payment instruction. The customer is redirected back to your success URL. A webhook fires to your backend. The session is marked complete.

Here is what that looks like from your backend:

POST /api/checkout/sessions
Authorization: Bearer sk_xxx

{
  "mode": "payment",
  "line_items": [{
    "price_data": {
      "currency": "usd",
      "product_data": { "name": "T-shirt" },
      "unit_amount": 2000
    },
    "quantity": 1
  }],
  "success_url": "https://yourstore.com/order/123",
  "cancel_url": "https://yourstore.com/cart"
}

The response includes a url field. You redirect your customer there. OpenCheckout handles the rest.

Why I Like How This Works

There are a few things that I have come to like about building OpenCheckout, as my first proper Open Payments-related experiment.

The protocol does the heavy lifting. Open Payments is genuinely well-designed. The separation of payment instructions from execution means OpenCheckout never touches money. The SDK handles key management, request signing, grant negotiation, and hash verification. Most of the security-critical work is inherited from the protocol, not reinvented in the application.

Wallet addresses are a better primitive than card numbers. A wallet address URL is discoverable, shareable, and verifiable. You can GET it to find out everything you need. There is no PAN, no CVV, and no expiry date to store. The customer authenticates at their own ASE. There is nothing to steal from the checkout page.

Self-hosted means zero marginal cost. SQLite just seems to be the best option as the database for now. The only external dependency is the Open Payments SDK. A merchant on a $0 or $6 VPS can run this indefinitely with no per-transaction overhead.

REST API reduces adoption friction. The checkout sessions API mirrors Stripe's shape. This means the same endpoint, field names, and idempotency behavior. A developer who has integrated Stripe can switch their backend to OpenCheckout by changing a base URL and an API key. This matters a lot for adoption.

The Architecture, Briefly

OpenCheckout is a Next.js application with three main surfaces:

The merchant API (/api/checkout/sessions) is the backend-facing REST interface. It is authenticated with API keys, supports idempotency, and validates all input against Zod schemas.

The checkout page (/pay/:sessionId) is the customer-facing UI. It shows the order summary in a cream color block, accepts a wallet address URL, and handles the redirect to the customer's authorization server for payment approval. After approval, a success page confirms the payment before forwarding to the merchant's success URL.

The orchestration engine (src/lib/open-payments/) wraps the Open Payments SDK and manages the full protocol lifecycle: wallet address resolution, incoming payment creation, quote requests, interactive grant handling, outgoing payment creation, and hash verification.

The dashboard (/dashboard) gives the merchant a view of their transactions, API key management, and webhook configuration. It uses a beautiful design system with pastel color blocks. I did this deliberately to make the checkout feel trustworthy.

What Testing Looked Like

I ran 20 real transactions through the Interledger test network — from $3.00 to $2,000.00 — between two wallet addresses, one denominated in EUR and one in USD. Every payment completed successfully. The exchange rate was applied automatically by the test ASE. The product descriptions also appeared in the transaction history on both sides. The redirect flow worked. The success page showed a countdown and forwarded to the merchant URL.

I think there is something satisfying about watching money move through software you built, through a protocol you did not build but chose to trust, between accounts at a provider you do not control. For me, it reinforces that the protocol is the product and that the protocol works.

What Comes Next

Although OpenCheckout is working as an experimental MVP, I still think there is so much for me to do. For instance, Open Payments adoption among account servicing entities is still early. The Interledger test network works today for development and testing. I believe that if more real ASEs implement the standard, the addressable market for OpenCheckout grows automatically.

Also, for OpenCheckout itself, I already have a roadmap that includes every other use case Open Payments supports. I also have to make sure there are more helpers I need to work on. However, I have made the code open-source under AGPLv3 at github.com/temidayoxyz/opencheckout.

Contributions, feedback, and questions are welcome.

If you have an Open Payments wallet and five minutes, you can be accepting payments on your own domain. That feels like something worth sharing.

CTRL+Pay: Helping Nigerian Freelancers Get Paid Easily

Temidayo Jacob — Fri, 11 Jul 2025 23:54:42 +0000

Hello. I am an advocate for financial inclusion, and I have 5 years of experience developing web solutions for diverse organizations, including e-commerce businesses, agencies, and nonprofits. I have been working on a solution, and I would like to share details about the project here.

Current Problem

According to the World Bank, as of 2023, there were about 17.5 million online gig workers in Nigeria, Kenya, and South Africa. Nigeria alone is known to have one of the largest freelance workforces in Africa. Yet Nigerian freelancers face some of the toughest payment challenges. PayPal doesn’t allow them to receive funds. Stripe doesn’t work for them. Bank transfers are expensive and slow. Payoneer and other platforms like Grey and Geegpay take big cuts, and USD to Naira conversions are rarely fair.

I believe that getting paid in U.S. dollars shouldn’t be so hard, especially when you’ve delivered the work to your client. But for millions of Nigerian freelancers and creative professionals, it’s an everyday struggle. I interviewed freelancers across major cities in Nigeria, who told me they have lost clients due to slow payments. They even mentioned that they have no control over how they receive and use their funds. It’s a broken system that is frustrating to freelancers and harmful to their business. CTRL+Pay was designed to change that.

CTRL+Pay as the Solution

CTRL+Pay solves this payment problem by letting Nigerian freelancers receive USD from clients from any part of the world fast, fairly, and securely. I built a working prototype that leverages open payment systems. With CTRL+Pay, freelancers can get paid directly into a USD wallet and then choose what to do next. They can either cash out to a domiciliary account, convert and cash out to their local banks in Naira, or hold the USD in their wallet for later.

It’s a simple platform with no middleman, no delays, and no hidden fees. Freelancers own the process and control their money.

User Flow of CTRL+Pay

Let’s walk through what happens on both sides.

Freelancer Side:

The freelancer signs up or signs in and creates a USD wallet.
A unique payment pointer (like $ctrlpay.com/username) is generated for easy invoicing.
They create an invoice, add project details, and price.
They generate a secure payment link (like ctrlpay.com/username/invoice-id) and send it to their client.
Once the client pays, the USD instantly arrives in the wallet, they get notified, and it updates in their transactions log.
The freelancer then chooses what to do with the money. To hold USD in wallet, to convert to Naira and send to a local bank, or to send USD to a domiciliary account. Even crypto withdrawals are allowed. It’s their choice.

Client Side:

The client receives the freelancer’s invoice payment link (it’s secure, and no login is needed).
They click and view the invoice details and choose their payment method.
Payment is made, confirmed, and verified immediately.
They are to receive receipts of payment.

This process is fast, clean, and transparent. It works across borders and payment systems, thanks to the flexibility of the Interledger Protocol.

Why It Works

While I built the CTRL+Pay prototype using Firebase Studio for frontend and backend logic, the Interledger Protocol makes this system instant and interoperable. For payments currently, I have integrated Paystack and Interledger. This will make CTRL+Pay future-proof and scalable. Nigerian freelancers can choose how they receive money, while clients enjoy a smooth experience. It’s a win-win for both.

The dashboard lets freelancers generate invoices, share links, and receive real-time payment alerts. It shows payment history and provides control over withdrawal methods. Client payment simulation is also there to make the process easy to understand. Everything is mobile-friendly and built with user simplicity in mind. The current prototype is live but semi-functional. I tested it with a few freelancers in Nigeria, and the feedback has been positive.

What’s Next?

For the production version, my plan is to develop a mobile application compatible with both Android and iOS platforms. I plan to remove Paystack and leverage only the Interledger Protocol. This means better performance, real-time settlement, and lower fees.

I also plan to integrate directly with local Nigerian banks and enable real-time automated withdrawals to domiciliary and Naira accounts. Also, I plan to integrate systems for cryptocurrency withdrawals to enable freelancers to withdraw their money into their crypto wallets in real time. Eventually, CTRL+Pay will be the go-to payments tool for Nigerian freelancers who work with clients from other countries.

Getting paid should be simple. For too long, Nigerian freelancers and creative professionals have had to fight just to access what they’ve earned. CTRL+Pay is designed to change that by making global payments easy, instant, and empowering, using Interledger. With this solution, everyone will be reminded that in a world obsessed with building for the West, we can still build for ourselves.

Link to the prototype: CTRL+Pay