DEV Community: Ryan Kelly

Payment APIs, Decoded: The Architecture Behind Flutterwave, Paystack, PesaPal, IntaSend, and Stripe

Ryan Kelly — Sat, 11 Jul 2026 19:16:45 +0000

If you've integrated a payment API before, you've probably followed a quickstart guide, pasted in a secret key, hit an endpoint, and shipped it. It works — until a webhook doesn't fire, a customer double-clicks "Pay Now," or a refund silently fails and support gets flooded with tickets.

This article isn't a quickstart guide. It's an attempt to explain why payment APIs are built the way they are,the failure modes they're designed around, and the tradeoffs different providers make — using five real providers as concrete reference points: Flutterwave, Paystack, PesaPal, IntaSend, and Stripe.

If you're a backend engineer who's touched one payment API and wants to understand the category, not just the vendor, this is for you.

1. What a Payment API Actually Is

A Payment API is a service that lets your application move money between two parties — a customer and a merchant — without your application ever directly touching a bank's core systems, a card network's rails, or a mobile money operator's ledger.

That's the whole point: you are not allowed to talk to banks directly, and even if you could, you wouldn't want to.

Why payment APIs exist

Banks, card networks (Visa/Mastercard), and mobile money operators (M-Pesa, Airtel Money) each expose their own proprietary, heavily regulated, and often decades-old interfaces. Integrating with each one directly would require:

Individual commercial agreements with every bank and network
Compliance certification for each rail (PCI DSS, ISO 8583 for card switching, telco-specific protocols for mobile money)
Handling settlement, reconciliation, and dispute resolution per rail
Maintaining uptime and security to a regulator-grade standard A payment API — usually operated by a payment gateway or payment aggregator — absorbs all of that complexity and exposes a single, consistent REST interface. You send JSON over HTTPS; they deal with ISO 8583 messages, telco USSD callbacks, and bank settlement files. ### Payment Aggregator vs Payment Gateway

These terms get used interchangeably, but there's a real distinction:

Payment Gateway: Routes a transaction to the correct processor/bank and returns a result. Conceptually similar to a network switch — it doesn't hold merchant funds.
Payment Aggregator: Onboards many small merchants under its own master merchant account with an acquiring bank, then sub-routes transactions internally. This is why you can sign up for Paystack or Flutterwave in minutes instead of weeks — you're not opening your own merchant account with a bank, you're a sub-merchant of theirs. Flutterwave, Paystack, IntaSend, and PesaPal are all aggregators. Stripe operates as both, depending on market and product (Stripe Connect explicitly turns you into an aggregator for your own sub-merchants).

The technical contract

Regardless of aggregator vs gateway, almost every modern payment API shares the same technical contract:

REST over HTTPS — no exceptions in 2026; TLS is non-negotiable given cardholder data sensitivity
JSON request/response bodies
Key-based authentication — API keys, bearer tokens, or OAuth, transmitted in headers, never in the URL or body
Idempotent, stateless requests — each API call carries everything needed to process it; state lives server-side on the provider This shared contract is exactly why, once you understand one payment API deeply, the rest become 80% pattern-matching and 20% provider-specific quirks.

2. Payment Processing Architecture

Here's the full lifecycle of a single payment, end to end:

 Customer
    │
    ▼
 Frontend (Web / Mobile App)
    │  (collects payment method, redirects to checkout)
    ▼
 Backend Server
    │  (creates transaction via secret key — NEVER from frontend)
    ▼
 Payment API (Flutterwave / Paystack / Stripe / etc.)
    │
    ▼
 Bank / Card Network / Mobile Money Operator
    │  (actual money movement happens here)
    ▼
 Payment Result
    │
    ├──────────────► Webhook ──────► Backend ──────► Database Update
    │
    └──────────────► Redirect ─────► Frontend Confirmation (UNTRUSTED)

Breaking down each component

Frontend: Collects payment intent — amount, method, maybe card details (tokenized client-side, never touching your server) — and either redirects to a hosted checkout page or opens an embedded payment element. The frontend's job ends at initiating the payment. It should never be the source of truth for whether a payment succeeded.

Backend Server: This is where your secret key lives, and it's the only component authorized to create transactions and query their real status. It initializes the payment, generates a reference ID for your own reconciliation, and later verifies the outcome.

Payment API: Receives the transaction request, validates it, and hands off to the actual settlement rail — a card network, a bank's account-to-account rail, or a mobile money operator's collection API (e.g., M-Pesa STK Push).

Bank / Card Network / Mobile Money: This is where money actually moves. Everything before this point is orchestration; this is execution.

Payment Result → Webhook: The provider doesn't wait for you to ask "did it work?" — it pushes an event to a webhook URL you registered, asynchronously, the moment the result is known. This decouples payment completion from your server being "in the room" at that exact millisecond.

Backend → Database Update: On receiving the webhook, your backend re-verifies the transaction (never trusts the webhook payload blindly — more on this in Section 4) and updates your own database as the single source of truth for your application.

Frontend Confirmation: The user is redirected back to your app and shown a success/failure screen — but this is a UX convenience, not a trust boundary. The database record written from the verified webhook is what actually determines whether the order ships.

This separation — frontend shows status, backend decides truth — is the single most important architectural idea in payment systems, and it's the one junior implementations get wrong most often.

3. The Universal Integration Workflow

Nearly every provider in this article — despite very different dashboards, docs, and SDKs — implements the same eleven-step sequence:

Create a merchant account with the provider (KYC/KYB verification happens here)
Obtain API credentials — typically a public/publishable key, a secret key, and sometimes an OAuth-issued access token or consumer key
Authenticate requests using those credentials, almost always via an Authorization: Bearer <SECRET_KEY> header
Create a payment request — amount, currency, customer info, and a merchant-generated reference ID
Provider creates a transaction record and returns something you redirect the user to — a checkout URL, a Payment Intent, or a payment session
Customer completes payment via card, mobile money, bank transfer, or wallet
Provider communicates with the underlying rail (bank, card network, telco)
Transaction completes (or fails) on that rail
API returns a response to whichever party is polling or redirected
Webhook fires, notifying your backend asynchronously
Backend verifies the payment against the provider's API directly, then fulfills the order ### A representative request

POST /transaction/initialize
Authorization: Bearer sk_live_xxxxxxxxxxxx
Content-Type: application/json

{
  "amount": 5000,
  "currency": "KES",
  "email": "user@email.com",
  "reference": "order_9f21ac"
}

Why the secret key never leaves your server

The secret key can create charges, issue refunds, and initiate payouts — essentially, it can move money. If it leaks into frontend JavaScript, mobile app bytecode, or a public repo, anyone can use it to drain funds or create fraudulent transactions attributed to your account. Public/publishable keys, by contrast, are safe client-side because they can only be used to tokenize payment details or initiate a session — never to unilaterally move money or query sensitive account data.

Why step 11 (verification) is non-negotiable

Step 9's API response and the frontend redirect in step 6 can both be spoofed, cached, or manipulated by a malicious client. A user could, in theory, intercept the redirect and forge a "success" URL without ever paying. The only trustworthy source of truth is your backend independently asking the provider, "what is the real status of transaction order_9f21ac?" — using your secret key, over a server-to-server call the client can't touch.

4. Core Backend Concepts

This is where payment APIs stop being "just another REST API" and start requiring systems-level thinking.

Payment Initialization

Before money moves, providers require you to declare intent — create a transaction object describing what you're about to charge, for how much, in what currency, before the customer ever enters payment details.

Why not just charge directly in one call? Because payments are rarely atomic in practice:

The customer might need to be redirected to a 3D Secure challenge, an OTP screen, or an STK push prompt on their phone
The amount might need adjustment (tips, currency conversion) before capture
You need a stable object to reference across multiple round trips (frontend polling, webhook correlation, retries) Stripe makes this explicit with Payment Intents — a stateful object that moves through requires_payment_method → requires_confirmation → requires_action → processing → succeeded. Flutterwave and Paystack achieve the same thing more implicitly: you call /transaction/initialize, get back a checkout URL, and the transaction object behind that URL tracks state server-side even though it's not exposed as a rich state machine to you.

Payment Verification

Rule: never trust a frontend "success" message.

The frontend can only tell you what the user's browser observed — a redirect parameter, a client-side SDK callback. None of that is cryptographically tied to an actual settled transaction. A user can manually craft a ?status=success URL, a proxy can rewrite responses, or a client bug can fire a success callback without the underlying payment ever completing.

The only reliable verification path is a server-to-server GET request, authenticated with your secret key, asking the provider directly:

GET /transaction/verify/{reference}
Authorization: Bearer sk_live_xxxxxxxxxxxx

You fulfill the order only when this call — not the redirect, not the webhook payload alone — confirms status: success.

Webhooks

Polling vs. webhooks is a classic distributed-systems tradeoff:

Polling (repeatedly calling GET /transaction/{id}) is simple but wasteful — you're guessing when the result will be ready, burning API quota and adding latency.
Webhooks invert the model: the provider pushes an event to you the instant a state change happens. This is event-driven architecture applied to payments — your backend reacts to events (charge.completed, payment.failed, refund.completed) instead of asking "are we there yet?" in a loop. A typical webhook backend flow:

Provider ──POST──► /webhooks/payment
                       │
                       ▼
             Verify signature (HMAC)
                       │
                       ▼
             Is this event new? (idempotency check)
                       │
                       ▼
             Re-verify via GET /verify (don't trust payload)
                       │
                       ▼
             Update database, trigger fulfillment
                       │
                       ▼
             Return 200 OK  (ack — or provider will retry)

Two details matter enormously here:

Signature verification — providers sign webhook payloads (usually HMAC-SHA512 over the raw body, using a webhook secret you generate). Skipping this means anyone who knows your webhook URL can forge a payment event.
Returning 200 quickly — providers retry failed/timeout webhook deliveries with backoff. Your handler should acknowledge fast and do heavy processing asynchronously (queue job), or you risk duplicate deliveries piling up. ### Idempotency

Networks fail. Clients retry. Users double-click. Any of these can cause the same payment intent to be submitted twice. Without protection, that's a double charge — a direct financial loss and a trust-destroying bug.

Idempotency keys solve this: the client generates a unique key per logical operation (not per HTTP call) and sends it in a header:

Idempotency-Key: order_9f21ac_attempt_1

If the provider sees the same key again — whether because of a genuine retry after a timeout, or a duplicate click — it returns the original result instead of creating a second charge. Stripe formalizes this as a first-class header (Idempotency-Key) with a documented retention window (typically 24 hours). Providers without a formal idempotency API (common among African aggregators) push this responsibility onto you: generate your own unique reference per attempt and treat duplicate references as a signal to fetch the existing transaction rather than create a new one.

This matters more in payments than almost any other domain — "eventually consistent, occasionally duplicated" is fine for a like button; it is not fine for a bank transfer.

Authentication

Mechanism	What it is	Where it's used
API Key (secret)	Long-lived static credential, full account privileges	Backend-only, all providers
API Key (public/publishable)	Restricted to safe client-side operations (tokenization, session creation)	Frontend SDKs, Stripe/Flutterwave/Paystack
Bearer Token	Credential sent in `Authorization` header	Universal transport mechanism for the above
OAuth Access Token	Short-lived, scoped, obtained via OAuth flow, often refreshable	Stripe Connect (platform-to-connected-account), some IntaSend flows
Consumer Key/Secret	OAuth 1.0/2.0-style credential pair used to obtain an access token	PesaPal, and the underlying M-Pesa Daraja API that several aggregators sit on top of

The security principle underneath all of these: credential scope should match blast radius. A publishable key leaking is a non-event. A secret key leaking is an incident. An OAuth token scoped to a single connected account leaking is bad, but contained — unlike a platform-wide secret key.

PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) is a compliance framework mandated by the card networks (Visa, Mastercard, etc.) for anyone who stores, processes, or transmits cardholder data. Compliance is expensive: network segmentation, quarterly vulnerability scans, annual audits, and strict access controls.

Payment APIs exist partly to keep you out of PCI scope. If your server never touches raw card numbers — because the card form is hosted by the provider (a redirect/iframe) or tokenized client-side via their JS SDK before it ever reaches your backend — your PCI compliance burden drops from "full assessment" (SAQ D) to a much lighter self-assessment (SAQ A), sometimes just a checklist.

The rule for merchants: never store raw card data. Ever. Not encrypted "for convenience," not in logs, not in error messages. Let the processor hold that liability.

Tokenization

Tokenization replaces sensitive data (a card number) with a non-sensitive token that's meaningless outside the system that issued it — it can't be reverse-engineered back into the original card number.

It's easy to confuse with two adjacent concepts:

Encryption: Reversible. If you have the key, you get the original data back. The card number still exists, mathematically recoverable.
Hashing: One-way and deterministic. Same input always produces the same output — which is exactly why hashing is wrong for card numbers (you could brute-force a hash of a 16-digit number space).
Tokenization: The mapping between token and real value lives only in the provider's secure vault. The token itself carries zero recoverable information. Even if your database of tokens leaks, an attacker gets nothing usable. This is why you can safely store a Stripe pm_xxxxx payment method token in your own database for recurring billing, but you could never safely store the underlying card number, encrypted or not.

Payment States

Every provider models roughly the same underlying state machine, even if the exact labels differ:

 Pending ──► Authorized ──► Captured ──► Completed
    │             │                          │
    │             └──► Cancelled             ├──► Refunded
    │                                          └──► Reversed
    └──► Failed

Pending: Transaction created, awaiting customer action or processing
Authorized: Funds reserved on the customer's account/card, not yet moved (common in card payments; less common in mobile money, which is usually a single-step debit)
Captured: Merchant confirms the authorized amount should actually be collected
Completed: Funds have settled to the merchant
Failed: Payment attempt did not succeed (insufficient funds, declined, timeout)
Cancelled: Authorized but voided before capture
Refunded: Completed payment returned to customer, fully or partially
Reversed: Provider- or bank-initiated reversal, often for fraud or disputes Understanding this state machine matters because your own database schema should mirror it — a transactions table with a loosely-typed status: string column and no enforced transitions is a recipe for "refunded" orders that still show as "completed" in your admin panel.

5. Provider Deep Dives

Flutterwave

Overview: Pan-African payment infrastructure company, headquartered with operations spanning Nigeria, Kenya, Ghana, Uganda, South Africa, and beyond, with growing support for cross-border and international card payments.

Supported countries: 30+ African countries, plus international card acceptance for global customers paying African merchants.

Payment methods: Cards (Visa/Mastercard/Verve), bank transfers, USSD, mobile money (M-Pesa, MTN MoMo, Airtel Money), Barter (Flutterwave's own wallet), virtual accounts, and payment links.

Technical architecture: REST/JSON over HTTPS, secret + public key authentication, sandbox and live environment separation, SDKs for Node.js, PHP, Python, and mobile (React Native, Flutter). Webhooks are HMAC-signed with a verif-hash header you compare against a secret you set in the dashboard.

Representative endpoints:

POST /v3/payments              # Initialize a transaction, get a checkout link
GET  /v3/transactions/{id}/verify   # Verify actual transaction status
POST /v3/transfers             # Payout to a bank account or mobile money wallet
POST /v3/refunds               # Refund a completed transaction

Strengths: Broad multi-country and multi-rail coverage in a single integration; strong mobile money support, which matters enormously for African markets where card penetration is low; virtual account and payment link features reduce custom checkout UI work.

Weaknesses: Documentation consistency has historically varied across API versions (v2 vs v3 migration pain is a known community complaint); error messages can be less granular than Stripe's.

Ideal use case: Multi-country African e-commerce or marketplace platforms that need one integration to reach customers across several currencies and payment rails, including mobile money.

Paystack

Overview: Nigerian-born payment gateway (acquired by Stripe in 2020), strongest in Nigeria and Ghana, expanding across the continent, widely praised for developer experience.

Supported countries: Nigeria, Ghana, South Africa, Kenya (growing), with card acceptance from a wider set of countries.

Payment methods: Cards, bank transfers, USSD, mobile money (Ghana), QR, and Paystack's own virtual accounts.

Technical architecture: Clean REST/JSON API, single secret-key bearer auth, extremely readable documentation with copy-pasteable examples in most major languages, well-maintained SDKs. Sandbox uses test-mode keys (sk_test_...) that mirror live behavior closely, making local development fast.

Representative endpoints:

POST /transaction/initialize   # Create transaction, get authorization_url
GET  /transaction/verify/{reference}  # The canonical "did this actually work" check
POST /transfer                 # Send money out (payouts)
GET  /customer/{code}          # Customer object for recurring billing
POST /refund                   # Full or partial refund

Strengths: Arguably the best developer experience of the African providers covered here — predictable naming, consistent error shapes, a Customers API that makes recurring billing straightforward, and a verification endpoint that's simple to reason about.

Weaknesses: Narrower country coverage than Flutterwave; mobile money support is less comprehensive outside specific markets.

Ideal use case: Nigeria/Ghana-first products, or teams that prioritize integration speed and clean documentation over maximal geographic reach.

PesaPal

Overview: East African payment gateway, one of the earliest players in the region, historically strong in Kenya, Uganda, Tanzania, with particular traction in hospitality (hotels, travel) and education (school fee payments).

Supported countries: Kenya, Uganda, Tanzania, Malawi, Zambia, with a regional East/Southern Africa focus rather than pan-continental breadth.

Payment methods: Cards, M-Pesa and other regional mobile money, bank transfers, and PesaPal's own wallet.

Technical architecture: OAuth-based authentication (consumer key/secret exchanged for a bearer token) rather than a static secret key — an important difference from Flutterwave/Paystack's simpler model. IPN (Instant Payment Notification) is PesaPal's term for what other providers call a webhook — you register an IPN URL that receives callback notifications on transaction status change.

Representative endpoints:

POST /api/Auth/RequestToken         # Exchange consumer key/secret for bearer token
POST /api/URLSetup/RegisterIPN      # Register your callback/webhook URL
POST /api/Transactions/SubmitOrderRequest  # Create a payment request
GET  /api/Transactions/GetTransactionStatus  # Verify status

Strengths: Deep, longstanding integrations in hospitality and education verticals in East Africa; reliable for recurring institutional use cases like school fees, which have specific reconciliation needs (matching payments to specific students/invoices).

Weaknesses: The OAuth token exchange step adds integration complexity versus a single static bearer key; smaller developer community and fewer third-party SDKs/tutorials than Paystack or Stripe; documentation is functional but less polished.

Ideal use case: Institutional East African use cases — schools, hotels, travel bookings — where PesaPal's existing vertical relationships and IPN reliability outweigh the extra OAuth complexity.

IntaSend

Overview: Kenyan payment infrastructure provider, positioned as a developer-friendly alternative for Kenya-specific and East African collections and payouts, with a strong focus on M-Pesa.

Supported countries: Primarily Kenya, with expanding regional support.

Payment methods: M-Pesa (STK Push is a headline feature — the "enter your PIN" prompt that pops up on the customer's phone), cards, bank transfers.

Technical architecture: REST/JSON, API key + publishable key pair similar to Paystack's model, dedicated Collections API (money coming in) and Payouts API (money going out) as clearly separated concerns rather than a single generic "transactions" endpoint. Sandbox environment available for testing STK Push flows without real Safaricom charges.

Representative endpoints:

POST /api/v1/payment/mpesa-stk-push/   # Trigger STK push to customer's phone
GET  /api/v1/payment/status/{id}/      # Check payment status
POST /api/v1/send-money/mpesa/         # B2C payout via M-Pesa
POST /api/v1/send-money/bank/          # Payout to bank account

Strengths: Excellent for M-Pesa-first products — the STK Push flow is well-documented and the separation of Collections vs. Payouts APIs maps cleanly onto how most businesses think about cash flow (money in vs. money out are genuinely different operational concerns, often owned by different teams). Good fit for Kenyan fintech and SME tooling.

Weaknesses: Narrower geographic and payment-method scope than Flutterwave or Stripe — if you need broad card acceptance outside Kenya or multi-country mobile money, you'll likely need a second provider alongside it.

Ideal use case: Kenya-first products where M-Pesa collections and payouts (e.g., a savings app, a gig-economy payout system, a merchant till replacement) are the core transaction type — which is directly relevant if you're building something like a creator-payout or livestreaming monetization flow with M-Pesa as a primary rail.

Stripe

Overview: The global reference implementation for modern payment infrastructure. If you're trying to understand "how should a payment API be designed," Stripe's API is usually the answer, and it's worth studying even if you never integrate it, because most other providers' newer API versions are visibly influenced by its patterns.

Supported countries: 40+ countries for full merchant accounts, with broader reach for accepting international cards.

Payment methods: Cards, bank debits (ACH, SEPA), wallets (Apple Pay, Google Pay), buy-now-pay-later options, and — through Stripe Connect — the ability to build your own multi-sided marketplace with sub-merchants.

Technical architecture — the deepest of the five, deliberately

Payment Intents API: Rather than a single "charge" call, Stripe models a payment as an object that moves through an explicit state machine (requires_payment_method → requires_confirmation → requires_action → processing → succeeded/requires_capture). This exists because modern card payments frequently require multi-step customer interaction — 3D Secure authentication being the most common — and Stripe's model was purpose-built to represent "this payment is in progress and waiting on the customer" as a first-class state, not an edge case bolted on afterward.

Setup Intents: For saving a payment method without charging anything yet — critical for free trials, "add a card" flows, or authorizing future off-session charges.

Checkout Sessions: A hosted, Stripe-managed checkout page — the fastest path to PCI-light integration, similar in spirit to Flutterwave/Paystack's hosted checkout URLs, but with deep customization options.

Billing & Subscriptions: A full subscription engine — proration, metered billing, trial periods, dunning (automatic retry logic for failed recurring charges) — that most African providers don't attempt to replicate at the same depth.

Connect: Turns your platform into a marketplace. You can onboard your own sub-merchants (creators, sellers, drivers) each with their own Stripe-managed account, and split payments between platform and seller programmatically. This is directly the pattern underneath most creator-economy and marketplace platforms.

Webhooks: Same event-driven model as other providers, but with a notably larger, more granular event taxonomy (payment_intent.succeeded, charge.dispute.created, invoice.payment_failed, etc.) and official libraries for signature verification in every major language.

Idempotency: First-class Idempotency-Key header support baked into the core API, not something you have to simulate with your own reference field.

Radar: Stripe's built-in fraud detection engine, using machine learning trained across Stripe's entire transaction graph — an advantage of scale that's very hard for smaller regional providers to replicate.

Payment Element: A single embeddable UI component that automatically shows the right payment methods for the customer's location and adapts to Stripe's evolving method support without you shipping new frontend code.

Representative endpoints:

POST /v1/payment_intents             # Create a Payment Intent
POST /v1/payment_intents/{id}/confirm  # Confirm with a payment method
GET  /v1/payment_intents/{id}         # Verify current status
POST /v1/refunds                      # Refund a charge
POST /v1/transfers                    # Move funds to a connected account (Connect)
POST /v1/subscriptions                # Create a recurring billing subscription

Strengths: Unmatched documentation quality, the richest state-modeling of any provider here, native idempotency, built-in fraud detection at scale, and Connect for marketplace architectures — this is genuinely the deepest, most "engineered" API in this comparison.

Weaknesses: Limited or no direct support for African mobile money rails (M-Pesa, Airtel Money) — you'd pair Stripe for global card/wallet coverage with a regional provider for mobile money if building for African markets specifically; pricing and payout timelines can be less favorable in some emerging markets.

Ideal use case: Global SaaS billing, marketplaces needing split payments (Connect), or any product where subscription logic, fraud tooling, and API maturity matter more than direct mobile money support.

6. Flow Diagrams

Payment Request Flow

Frontend            Backend              Payment API           Bank/Telco
   │                   │                      │                    │
   │  "Pay $50"        │                      │                    │
   ├──────────────────►│                      │                    │
   │                   │  Initialize (secret key)                  │
   │                   ├─────────────────────►│                    │
   │                   │                      │  Route to rail     │
   │                   │                      ├───────────────────►│
   │                   │  checkout_url        │                    │
   │                   │◄─────────────────────┤                    │
   │  Redirect to      │                      │                    │
   │◄──────────────────┤                      │                    │
   │  checkout_url     │                      │                    │
   │───────────────────┴─────────────────────►│  Customer pays     │
   │                                           ├───────────────────►│

Webhook Flow

Bank/Telco ──► Payment API ──► POST /webhooks/payment ──► Your Backend
                                                               │
                                                    ┌──────────┴──────────┐
                                                    │ Verify HMAC signature│
                                                    └──────────┬──────────┘
                                                               │
                                                    ┌──────────┴──────────┐
                                                    │  GET /verify/{ref}   │
                                                    │  (re-check via API)  │
                                                    └──────────┬──────────┘
                                                               │
                                                    ┌──────────┴──────────┐
                                                    │  Update DB, fulfill  │
                                                    └──────────┬──────────┘
                                                               │
                                                          Return 200 OK

Refund Flow

Merchant Backend                 Payment API                    Bank/Card Network
       │                              │                                │
       │  POST /refund {tx_id, amt}   │                                │
       ├─────────────────────────────►│                                │
       │                              │  Reverse settlement request     │
       │                              ├───────────────────────────────►│
       │                              │  Refund confirmed               │
       │                              │◄───────────────────────────────┤
       │  refund.completed (webhook)  │                                │
       │◄─────────────────────────────┤                                │
       │  Update order status         │                                │

Payout Flow (e.g., paying a creator/driver/vendor)

Merchant Backend               Payment API                Bank / Mobile Money
       │                            │                              │
       │  POST /transfer            │                              │
       │  {amount, destination}     │                              │
       ├───────────────────────────►│                              │
       │                            │  Disburse funds               │
       │                            ├─────────────────────────────►│
       │                            │  transfer.completed webhook   │
       │◄───────────────────────────┤◄──────────────────────────────┤
       │  Reconcile payout ledger   │                              │

Subscription Flow (Stripe-style, conceptually generalizable)

Customer          Backend            Payment API
   │                 │                    │
   │  Sign up         │                    │
   ├────────────────►│                    │
   │                 │ Create Customer     │
   │                 ├───────────────────►│
   │                 │ Attach payment method (Setup Intent)
   │                 ├───────────────────►│
   │                 │ Create Subscription │
   │                 ├───────────────────►│
   │                 │                    │  Billing cycle triggers
   │                 │                    │  invoice.payment_succeeded
   │                 │◄───────────────────┤  (or _failed → dunning retries)
   │                 │ Update entitlement  │

Payment Verification Flow

             ┌────────────────────────────────────┐
             │  NEVER trust frontend redirect alone │
             └────────────────────────────────────┘
                             │
Frontend redirect ──►  Backend  ──►  GET /verify/{reference}  ──►  Payment API
                             │                                          │
                             │◄─────────────── status: success ────────┤
                             │
                    Only NOW: fulfill order

8. Closing Thoughts

Strip away the branding, the dashboards, and the marketing copy, and every payment API in this article is solving the same handful of hard problems:

How do we let two parties who don't trust each other exchange money safely? (Aggregation, PCI scope reduction, tokenization)
How do we know a payment actually happened, when the client can lie? (Server-side verification, never trusting redirects)
How do we react to money movement without polling forever? (Webhooks, event-driven design)
How do we prevent a network hiccup from charging someone twice? (Idempotency)
How do we model something as messy as "a payment" as clean software state? (Payment state machines — pending, authorized, captured, refunded) Flutterwave and IntaSend lean into African payment rails and mobile money. Paystack optimizes for developer velocity in West Africa. PesaPal owns institutional East African verticals. Stripe pushes the ceiling on what a payment API's engineering can look like — richer state, native idempotency, built-in fraud detection, and a real subscription/marketplace layer.

None of them is "the best" in the abstract. The right provider is the one whose rails match your users' money and once you understand the shared architecture underneath all of them, switching providers, or running two in parallel, stops being a rewrite and starts being a config change.

If you're building payment infrastructure for African markets specifically — say, a platform combining M-Pesa collections with a token-based creator economy — the practical pattern that emerges from this comparison is: pick a mobile-money-native provider (Flutterwave or IntaSend) for local collections/payouts, and reserve Stripe-style depth (Connect, subscriptions, Radar) for the parts of your system dealing with global cards or platform-level fund splitting. Very few products need to build all of that state-machine complexity themselves — that's exactly the point of these APIs existing.

The Best Career Guidance Is a Tech Event You Didn't Want to Attend

Ryan Kelly — Sat, 13 Jun 2026 19:55:01 +0000

I have a confession: I almost didn't go to any of them.

Each time, there was a reason not to. Too far. Too expensive. Too early on a Saturday. Too many things on my plate. Too much imposter syndrome whispering what would you even say to a Google recruiter?

But I went. And every single time, I walked away with something that no tutorial, no documentation, no YouTube video had ever given me — a clear picture of where I stood, where the industry was moving, and exactly what I needed to do next.

This is the story of four events that quietly rewired how I think about my career as a developer. Not all at once. Not dramatically. But brick by brick, event by event — a map started taking shape.

Event 1: The Cursor × Claude Hackathon — The Day I Stopped Just Writing Code

I want to be honest: I signed up mostly because it was free.

The pitch was something about "agentic engineering" and "AI workflows," and I had a vague sense that I should probably know what those words meant. What I didn't expect was that within the first hour, my entire mental model of what it means to be a developer would be gently — and then violently — shaken.

The format was a one-hour build challenge. Ship a working, deployed prototype. In sixty minutes. Using Cursor and Claude.

I remember thinking: that's not possible.

And then watching a team beside me finish in forty-three.

What happened in that room wasn't just about speed. It was about a shift in how you relate to code. Up until that day, I had been — and I say this with zero shame — vibecoding. Generating, accepting, tweaking, generating again. Treating AI as a very fast autocomplete. The code shipped, sure, but I wasn't growing.

The hackathon exposed the ceiling on that approach.

The facilitators introduced a concept I hadn't heard articulated so cleanly before: agentic engineering — the practice of thinking in workflows, not lines. Instead of asking an AI to write a function, you define a system: what the agent needs to know, what tools it has access to, what a successful outcome looks like, and where you sit in the loop as the supervisor, not the typist.

The distinction they drew — and it stuck with me — was between Cursor and Claude Code as two philosophies. Cursor is the intelligent collaborator inside your IDE, human-in-the-loop at every step. Claude Code is the autonomous agent in your terminal, capable of reading, modifying, and reasoning over an entire codebase while you review rather than write. Neither is better. But understanding when to use which, and how to structure your prompts as architecture rather than requests — that's the skill.

I left with a deployed prototype, yes. But more importantly, I left with a question I've been sitting with since: Am I building with AI, or am I just letting AI build for me?

There's a version of every developer's future where they become an orchestrator — someone who designs multi-agent workflows, defines constraints, reviews outputs, and ships faster than any solo engineer ever could. That future was previewed in that room and I realised I needed to start preparing for it now.

Event 2: Nation.dev — The Uncomfortable Mirror

If the hackathon told me how to build better, Nation.dev showed me where I stood in the global picture.

And the global picture was not flattering — for any of us.

Nation.dev was a community-forward tech event focused squarely on the question that's haunting every developer right now but most of us are too proud to ask out loud: What is our place in the age of AI?

The opening speaker didn't waste time. The slide that stopped the room read something like: "The average software developer job description is being rewritten. Not next year. Now."

They weren't being paranoid. They were being precise. The data they walked us through painted a picture I had been half-aware of but hadn't confronted:

Global demand for junior developers is compressing as AI handles increasing amounts of boilerplate and scaffolding logic.
The developers who are thriving are those who moved up the value chain — closer to product, architecture, and business logic — while letting AI handle the mechanical layers below.
Africa, and Kenya specifically, is at an inflection point. We have one of the fastest-growing developer communities on the continent, a young population, and genuinely world-class talent coming out of programs like Zone01, Moringa, and others. But we're also at risk of building a generation of developers who are highly skilled at a layer of abstraction that AI is rapidly commoditising. The conversation that hit hardest was about positioning. Not skills — positioning. The speaker argued that the question isn't whether you can write Go, Python, or TypeScript. The question is: what problem do you uniquely understand? An African developer who deeply understands M-Pesa integration, informal financial systems, low-bandwidth UX, or cross-border remittance flows has a competitive advantage that no model trained on Stack Overflow can replicate. Your context is your moat.

I walked out of Nation.dev slightly bruised but newly focused. I stopped thinking about my career as a list of languages and started thinking about it as a set of problems I was uniquely positioned to solve.

Event 3: Build From Here Conference — The Room Where They Told You the Truth.

Most career advice is sanitised. "Keep learning." "Build your portfolio." "Network." "Be passionate." It's not wrong. It's just not particularly useful.

Build From Here was the first event where I heard people with actual hiring power and actual war stories speak without a filter.

The lineup was stacked in a way I hadn't seen at a local event before: Google recruiters, CTOs, PMs, and founders — not as distant keynote speakers, but in a format that felt genuinely conversational. These were people who had interviewed thousands of candidates, built products from zero to scale, and made or missed critical career bets. And they were telling you exactly what they wished candidates understood.

A few things I scribbled down and haven't stopped thinking about:

On interviews:
The Google recruiters were refreshingly direct. They're not primarily looking for people who know everything. They're looking for evidence of how you think when you don't know something. The candidate who walks through their reasoning — even imperfectly — consistently outranks the one who either knows the answer cold or goes blank. Thinking out loud is a skill. Practice it.

On what companies actually look for:
One CTO put it plainly: "I can teach almost any technical skill in six months. I cannot teach curiosity, ownership, or the ability to sit with ambiguity without panicking." The traits that get you through the door are trainable. The traits that get you promoted are harder to fake. Know which you're developing.

On sneaking into the job market:
This is the part that felt almost too honest. Multiple speakers talked about the myth of the "perfect application" — that idea that you need every checkbox ticked before you apply. One founder said she'd hired some of her best engineers because they reached out directly, had done homework on the company's actual problems, and proposed a specific idea for how they could help. Cold. Unsolicited. Hired.

The lesson: the formal application pipeline is one path, not the only path. GitHub contributions to projects a company uses. Public writing about problems in their domain. A cold email with a specific, well-researched observation. These are not shortcuts — they're alternate routes that most candidates never take because they require more initiative.

On positioning yourself:
A PM who'd hired across multiple companies offered a framing I've used since: think of your resume not as a history of what you've done, but as a prediction of what you'll do next. Every line should answer the implicit question: "Why is this person the right bet for where we're going?"

Build From Here didn't give me a job. It gave me a map of how the game is actually played — and the confidence to play it intentionally rather than just hoping to get lucky.

Event 4: Africa Free Routing — Bitcoin, the Lightning Network, and Building for Your Continent

I'll be honest again: I almost skipped this one too.

"Bitcoin developer bootcamp" felt far from where I was focused. I was deep in Go backends, API design, concurrency — the usual Zone01 territory. What did I need with wallets and mining?

Everything, as it turns out.

Africa Free Routing is, in their own words, a network of lightning nodes across Africa — built by Bitcoiners who believe that the Lightning Network can do for payments in Africa what mobile money did a decade ago, but faster, cheaper, and without the gatekeeping. Their five-day developer bootcamp in Kisumu was one of the most technically dense and philosophically rich experiences I've had.

Day one: what Bitcoin actually is. Not the price. Not the hype. The protocol. How transactions are constructed, signed, and broadcast. How the blockchain actually works as a data structure. And why, in a continent where a significant percentage of the population remains unbanked or underbanked, a permissionless, programmable money layer is not an abstract concept — it's infrastructure.

The Lightning Network was where things got deeply interesting for a backend developer. The Lightning Network is Bitcoin's Layer 2 — a system of payment channels that let two parties transact off-chain at high speed and extremely low cost, settling to the main chain only when they need to. Building on Lightning means thinking about channel capacity, routing, node management, and liquidity — problems that are architecturally fascinating and genuinely unsolved at scale in Africa.The bootcamp wasn't just teaching you about Bitcoin. It was recruiting you into building the infrastructure that doesn't exist yet.

By day three, we were creating wallets, managing channels, and by day four, exploring how to build applications — payment systems, micropayment platforms, remittance tools — on top of the Lightning stack.

The insight that landed hardest wasn't technical. It was strategic. The Afrobitcoin Fellowship and organisations like Btrust Builders and Chaincode Labs are actively backing developers and enthusiasts building in the African Bitcoin space — and the talent pool is still very thin. Thin talent pool in a growing, well-funded ecosystem means opportunity. The developers who understand this infrastructure deeply, who know how to connect M-Pesa flows to Lightning channels, who can build custody solutions that work on 2G — those developers are not competing against the global market. They're building the market.

I left with a working Lightning wallet, a GitHub repo with a basic payment app skeleton, and a radically expanded sense of what "backend development" could mean.

The Thread Connecting All Four

Step back and look at these four events together, and a single story emerges:

The Cursor/Claude hackathon told me that the craft of software engineering is changing faster than most of us have admitted. The developers who survive and thrive will be the ones who learn to think in systems and workflows, not just functions and files.

Nation.dev told me that the global market is brutal and honest: AI is compressing the value of generic technical skill, and the developers who win will be the ones who combine technical ability with deep domain knowledge — particularly the kind of domain knowledge that comes from living in Africa and understanding African markets.

Build From Here gave me the tactical layer — the unfiltered view of how hiring actually works, how to position myself, and how to take the initiative instead of waiting for permission.

Africa Free Routing showed me an entire frontier — financial infrastructure, Bitcoin, the Lightning Network — where skilled developers are scarce, the problems are real, and the impact potential is enormous.

None of these insights came from a course. None of them came from a YouTube video, a Twitter thread, or a dev.to article. They came from being in a room with people who were building real things and were willing to be honest about it.

The best career guidance I've ever received didn't come from a mentor sitting across a table, telling me what to do. It came from showing up, slightly unsure, to a room full of people who were a few steps ahead — and paying attention.

Go to the event. Especially the one you almost didn't.

I Built a TCP Chat Server in Go Before I Understood Concurrency — Here's What Taught Me Goroutines, Channels, and Mutexes.

Ryan Kelly — Fri, 05 Jun 2026 19:04:17 +0000

How building a Net-Cat clone became my crash course in Go concurrency.

Where It Started

When I first received the Net-Cat project, I thought it sounded pretty straightforward: build a TCP chat server, allow multiple clients to connect, let users choose usernames, broadcast messages, store chat history, and display join and leave notifications.

Simple enough, right? Not quite.

At the time, I knew some Go. I could write functions, work with structs, create packages, and build basic applications. What I didn't understand was concurrency.

I had heard people talk about it constantly — "Go is great because of concurrency," "use goroutines," "channels are amazing," "watch out for race conditions." I had heard all of those phrases. The problem was that if someone had stopped me and asked:

"What exactly is a goroutine?"
"Why would you use a channel?"
"What problem does a mutex solve?" I wouldn't have had a good answer. Building this chat server changed that.

This wasn't just a networking project. It became the project that finally made Go's concurrency model click for me.

The First Question I Had to Answer

Before thinking about goroutines, channels, or mutexes, I had to answer a simpler question: how should the application be structured?

After several redesigns, I landed on this:

.
├── main.go
├── server/
│   ├── server.go
│   ├── client.go
│   ├── room.go
│   ├── hub.go
│   ├── message.go
│   └── format.go
└── utils/
    └── ascii.go

Looking at this now, it seems obvious. It definitely wasn't obvious while building it. The architecture only emerged after I started running into problems — and those problems are what taught me concurrency.

Concurrency Was Just a Buzzword Until This Project

Before this project, concurrency felt like one of those concepts everyone talks about but nobody explains in a way that sticks.

Then I started thinking about my server. If one client connects and starts chatting, what happens when another client connects? And another? And another? Surely the server can't just stop talking to one client every time a new one arrives.

That was the first time I encountered a real concurrency problem: multiple things needed to happen at the same time. That's where goroutines entered the picture.

What Is a Goroutine?

The simplest explanation I can give: a goroutine is a lightweight task that runs independently.

Without goroutines, a program typically runs one instruction after another:

Do A → Do B → Do C → Done

But a chat server doesn't work like that. A chat server has many users connected simultaneously, each able to send messages whenever they want. If the server handled one client at a time, everybody else would be stuck waiting.

Instead:

go handleClient(conn)

That single keyword — go — creates a new goroutine. Now each client gets its own independent execution flow:

Server
 ├── Client 1
 ├── Client 2
 ├── Client 3
 └── Client 4

The moment I understood this, something clicked. The server wasn't one program anymore. It was lots of little workers running concurrently.

The Moment Goroutines Became Real

One of the biggest realizations came when implementing clients. Every client ended up needing two goroutines — one for reading messages, one for writing messages.

At first I thought: "Why two?" Then I realized both operations block. Reading blocks while waiting for user input. Writing blocks while waiting for outgoing messages. Those are completely independent activities.

go client.Read()
go client.Write()

Now both can happen simultaneously. The client can receive messages while also sending them. That sounds obvious now. It wasn't obvious to me then.

What Is a Channel?

The best explanation I found: a channel is a pipe/pathway

One goroutine puts data in. Another goroutine takes data out.

messages := make(chan string)

// Send
messages <- "Hello"

// Receive
msg := <-messages

The sender doesn't need to know who's receiving. The receiver doesn't need to know who's sending. The channel sits between them — like a mailbox:

Sender → Channel → Receiver

How Channels Powered My Chat Rooms

Once I understood channels, the room architecture started making sense. A room wasn't just storing data — it was receiving events.

type Room struct {
    broadcast chan Message
    join      chan *Client
    leave     chan *Client
}

Suddenly everything became event-driven:

room.join <- client      // Client joins
room.leave <- client     // Client leaves
room.broadcast <- msg    // New message arrives

The room simply listens for events:

func (r *Room) Run() {
    for {
        select {
        case client := <-r.join:
            // handle join

        case client := <-r.leave:
            // handle leave

        case msg := <-r.broadcast:
            // handle message
        }
    }
}

Before this project, select looked like weird Go syntax. After building the room system, it finally made sense. The room wasn't constantly checking for work — it was sleeping until something happened, waking up to handle it, then waiting again.

That was probably my first real "aha" moment with channels.

The Bug That Taught Me About Blocking

Then I hit a very important bug. My first broadcast implementation looked like this:

for client := range r.Clients {
    client.Send <- msg
}

Looks fine, and it worked — until I started thinking about slow clients. What if somebody stops reading messages? Eventually their channel fills up. Then this line blocks. And once it blocks, the room blocks, the broadcasts block, and the entire chat freezes.

One slow client could affect everyone.

The solution:

for client := range r.Clients {
    select {
    case client.Send <- msg:
    default:
        close(client.Send)
        delete(r.Clients, client)
    }
}

Now one problematic client can't bring down the entire room. This taught me an important lesson: concurrent systems must be designed around the possibility that things will fail.

Then I Met My First Race Condition

At this point I thought channels solved everything. They didn't.

The Hub stored rooms:

type Hub struct {
    rooms map[string]*Room
}

Imagine: Client A creates a room, Client B reads a room, and Client C deletes a room — all simultaneously. Multiple goroutines touching the same data. This is called a race condition, and that's where mutexes entered my life.

What Is a Mutex?

The simplest explanation: a mutex is a lock.

Think of a bathroom key. If one person has it, everyone else waits. When they're done, they return it, and someone else can enter.

mu.Lock()
rooms["general"] = room
mu.Unlock()

While the lock is held, nobody else can modify the shared data. This prevents corruption and inconsistent state.

How Mutexes Saved My Hub

The Hub became the single source of truth for rooms:

type Hub struct {
    rooms map[string]*Room
    mu    sync.RWMutex
}

Whenever rooms were created or modified:

h.mu.Lock()
defer h.mu.Unlock()

Whenever rooms were simply being read:

h.mu.RLock()
defer h.mu.RUnlock()

Before this project, mutexes felt mysterious. After this project, they felt practical. They solve a very specific problem: protecting shared data.

The Mental Model That Finally Clicked

This is the explanation I wish someone had given me at the beginning:

Need multiple things happening at once?  →  Use Goroutines
Need goroutines to communicate?          →  Use Channels
Need to protect shared data?             →  Use Mutexes

For a long time I treated these as separate, unrelated concepts. They're actually different tools solving different parts of the same problem.

The Hub: My Biggest Architectural Lesson

One thing I learned that had nothing to do with syntax was ownership. Initially the server managed rooms, and that became messy very quickly. Eventually I introduced a Hub, which became solely responsible for:

Creating rooms
Finding rooms
Moving clients between rooms
Cleaning up rooms Nothing else could do those things. Everything went through the Hub.

The lesson was simple: when many parts of a system need access to something, create one source of truth. It makes concurrent systems much easier to reason about.

The Import Cycle That Taught Me About Package Design

At one point I accidentally created this:

server → utils
utils  → server

Go immediately refused to compile:

import cycle not allowed

At first this was frustrating. Then I realized Go was protecting me. The formatter belonged next to the Message type, not in utils. Moving it into the server package solved everything.

Sometimes compiler errors are actually architecture lessons.

Testing Changed How I Thought About Code

The race detector was one of the most useful tools I discovered:

go test -race ./...

It caught problems I didn't even know existed. Running with -race has become automatic whenever I'm working on concurrent code. If you're learning Go concurrency, use it early — it will save you hours.

Concurrency Cheat Sheet

Tool	Purpose	Mental model	Example
Goroutine	Run work concurrently	A lightweight worker	`go handleClient(conn)`
Channel	Allow goroutines to communicate	A pipe or mailbox	`messages <- msg`
Mutex	Protect shared data	A lock on a door	`mu.Lock(); defer mu.Unlock()`

What I Know Now That I Didn't Know Then

When I started this project, concurrency was just a word I heard experienced developers use. I didn't know what goroutines actually were. I didn't understand channels. I had never used a mutex.

By the end, those concepts weren't just definitions anymore — they were solutions to problems I had personally encountered:

Goroutines helped me handle multiple clients simultaneously.
Channels helped components communicate safely.
Mutexes protected shared state from corruption. Most importantly, I learned that concurrency isn't really about goroutines or channels. It's about coordination — deciding who owns data, how information flows, and what happens when something goes wrong.

Building this chat server didn't just teach me how to write concurrent Go code. It taught me why those concurrency tools exist in the first place. And that's a lesson I don't think I would have learned from a tutorial alone.

Built during my Go learning journey at Zone01 Kisumu, Kenya. If you're learning Go and concepts like goroutines, channels, and mutexes still feel abstract — build something that forces multiple things to happen at the same time. For me, this chat server was the project that finally made everything click.

Why Project-based learning works: How I Built a Live Platform while learning Go.

Ryan Kelly — Fri, 05 Jun 2026 17:03:43 +0000

Building a real-world education platform for Kenyan university students — in a language I'd never touched before.

The Problem That Started Everything

Every Kenyan university student knows the pain. A lecturer recommends a textbook that costs more than a full month's budget. Someone shares useful notes in a WhatsApp group and three weeks later nobody can find them. You open an edtech app and it spins forever because the campus internet can't handle it.

ElimuLocal is my answer — a free, offline-capable platform where university students upload and share notes, past papers, textbooks, and lecture videos with each other. No paywalls. Works on campus WiFi with zero internet. Deployed live at elimulocal.onrender.com.

And I built the entire backend in Go — a language I started learning from scratch on the same day I started the project.

Why Go? Why Learn While Building?

Before ElimuLocal I hadn't written a single line of Go. The decision was deliberate.

Go compiles to a single binary with no runtime. A campus administrator can deploy ElimuLocal by downloading one file and running it — no Node version conflicts, no Python virtual environments, no JVM. Its standard library is powerful enough to build a complete web server without a framework.

But the most important reason was philosophical: learning while building is the only way I know how to learn properly. Reading a tutorial gives you syntax. Solving a real problem gives you understanding. Every Go concept I encountered during this build stuck because I needed it — not because it appeared on a syllabus.

Month 1 — The Foundation (March 2026)

The First Go Program

package main

import ("fmt"; "net/http")

func homeHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "ElimuLocal is working!")
}

func main() {
    http.HandleFunc("/", homeHandler)
    http.ListenAndServe(":8080", nil)
}

Six lines. A working HTTP server. I learned package main, handler functions, http.HandleFunc, and http.ListenAndServe — all in one sitting. I ran go mod init elimulocal, pushed to GitHub, and had something running on day one. That momentum matters.

Data Models and HTML Templates

Go's html/template standard library meant zero third-party dependencies for rendering pages. To pass data to a template you define a struct — this is where Go's type system started making sense:

type Resource struct {
    ID, Downloads, Upvotes, UserID int
    Title, Course, University      string
    Category, Description          string
    UploadedBy, UploadedAt         string
    FileName                       string
}

I used template composition — {{define "base"}} and {{template "content" .}} — so the navbar and footer were written exactly once. This step taught me slices, maps, range loops, and the strings package, all in the context of building a real university filter.

SQLite and File Uploads

I chose modernc.org/sqlite — a pure-Go driver requiring no C compiler, CGO_ENABLED=0 compatible. Critical for Docker later.

Parameterized queries protected against SQL injection from day one:

_, err := db.Exec(
    `INSERT INTO resources (...) VALUES (?, ?, ?, ?, ?, ?, ?, ?, 0, 0, ?)`,
    r.Title, r.Course, r.University, r.Category,
    r.Description, r.UploadedBy, r.UploadedAt, r.FileName, r.UserID,
)

File uploads used io.Copy() to stream directly to disk — no loading the whole file into memory. Unique filenames came from time.Now().UnixNano() to prevent collisions.

Offline by Design

ElimuLocal must work with zero internet. That meant self-hosting fonts. I downloaded Sora and Space Mono locally and served them via Go's built-in static file server:

fs := http.FileServer(http.Dir("static"))
http.Handle("/static/", http.StripPrefix("/static/", fs))

One line. An entire static file server. No configuration needed.

Month2 - Polishing and improvements.

Dynamic Search and Filtering

Students wanted to filter by category and sort by popularity or helpfulness. This introduced dynamic SQL construction — building queries conditionally based on active filters.
The []interface{} variadic argument list was a real Go moment — I had to understand how Go handles dynamic argument counts to make safe parameterized dynamic queries work.

Upvotes, Flash Messages, and LAN Deployment

The upvote handler taught me a clean HTTP pattern: reading the Referer header to redirect users back to their exact search results page after voting — preserving all their active filters.

Flash messages after uploads used ?success=1 query parameters — pure stateless HTTP, no session needed for simple confirmations.

Then came the first real test: I found the server's local IP, verified firewall settings, and accessed ElimuLocal on a real Android phone over campus WiFi. Seeing a resource uploaded on a laptop appear instantly on a phone across the room was the first time ElimuLocal felt like a real product.

Month 3 — Auth, Video, and Production (May 2026)

User Authentication in `auth.go`

Authentication was complex enough to earn its own file — and immediately taught me that go run main.go becomes go run . when your project spans multiple files.

Password hashing used bcrypt at cost factor 12:

func HashPassword(password string) (string, error) {
    bytes, err := bcrypt.GenerateFromPassword([]byte(password), 12)
    return string(bytes), err
}

Raw passwords never touch the database. Only hashes are stored.

Session management with gorilla/sessions introduced my hardest bug of the project. Without this one line:

func init() {
    gob.Register(int(0)) // Critical — without this, sessions silently fail
}

The session would be created on login, but on the next request the user ID would come back as zero. The user appeared logged out immediately. init() is Go's mechanism for package-level setup that runs automatically — and gob.Register tells the encoder what types to expect. Silent failure, hard lesson, one line fix.

The type switch for decoding session values was another Go pattern I learned solving a real problem:

switch v := session.Values["userID"].(type) {
case int:     userID = v
case int64:   userID = int(v)
case float64: userID = int(v)
default:      return User{}, false
}

Video Uploads and the `500 << 20` Idiom

Supporting lecture videos meant raising the upload limit and extending server timeouts:

r.ParseMultipartForm(500 << 20) // 500MB — bit shift idiom for byte sizes

server := &http.Server{
    ReadTimeout:  300 * time.Second, // 5 min for slow campus uploads
    WriteTimeout: 300 * time.Second,
}

MIME type detection by file extension drove the preview page — the same data model, either a PDF.js viewer or an HTML5 <video> element, decided entirely in Go before the template renders.

Dockerization with Multi-Stage Builds

The Dockerfile uses multi-stage building — the most important Docker pattern for Go.
The builder stage carries the full Go toolchain (300MB+). The production image has only the binary, templates, and static files. Tiny. CGO_ENABLED=0 produces a fully static binary that runs on any Linux container with zero shared library dependencies.

Database Migrations

As the schema evolved I needed reliable, repeatable migrations. migrate.go reads all .sql files from migrations/ in order, checks a schema_migrations tracking table, and runs each unapplied migration inside a transaction:

tx, err := db.Begin()
if _, err = tx.Exec(string(content)); err != nil {
    tx.Rollback()
    log.Fatalf("migrations: failed to apply %s: %v", name, err)
}
tx.Exec("INSERT INTO schema_migrations (filename) VALUES (?)", name)
tx.Commit()

Three migrations tell the project's story: users table, resources table, and a backfill that linked pre-auth uploads to their authors by matching usernames.

The Infrastructure Stack

Every choice was deliberate and free:

Turso (libsql) — SQLite with cloud persistence. The entire Go database layer works identically against local SQLite and Turso. Only the connection string differs, toggled by environment variables at startup.

Backblaze B2 — S3-compatible storage with no credit card required for the free tier. Switching to any other S3-compatible provider means changing environment variables only. The Go code never changes.

Render — Docker container hosting that builds and deploys on every push. No servers to manage.

Cloudflare — DNS, proxying, and SSL termination. elimulocal.onrender.com gets HTTPS for free.

What Learning While Building Actually Looks Like

This is not the story of someone who learned Go and then built ElimuLocal. It's the story of someone who learned Go by building ElimuLocal.

Every concept arrived when I needed it. Structs the day I needed a data model. Parameterized SQL the day I needed injection protection. gob.Register the day sessions silently broke. Multi-stage Docker the day I needed a small production image.

The failures were real — and they taught me things no tutorial surfaces. The go run . discovery. The gob type registration. The ReadTimeout for video uploads. You find these when a real problem forces you to. Not on a syllabus.

If you're waiting until you feel ready to learn a new language — don't. Start building something real instead. The readiness comes from the building.

What's Live Today

ElimuLocal at elimulocal.onrender.com: browse and search by keyword, university, and category; upload PDFs and lecture videos up to 500MB; preview PDFs in-browser with self-hosted PDF.js; stream videos via HTML5; download for offline reading; upvote and rate resources; full user accounts with edit and delete. Animated GSAP landing page. Docker-deployed. Cloudflare-fronted HTTPS.

Works on campus WiFi with zero internet. Works from anywhere via the cloud.

Built by Ryan Kelly — Zone01 Kisumu, Kenya — 2026

GitHub: github.com/Rkelly-dot/elimulocal · Live: elimulocal.onrender.com

What Comes Next

Month 4 roadmap: campus sync so resources uploaded on LAN are immediately available via cloud; auto-routing that detects whether a student is on campus and picks the fastest server; multi-campus namespace support; and M-Pesa billing integration for institutions that want a premium tier.

The architecture already supports it — shared Turso database, shared B2 storage, Docker everywhere. The foundation is solid.

If you would like to help me better my platform or have feedback, please feel free to reach out and have a look at my github. Otherwise help me grow the platform by sharing learning resources in it and make a difference by helping millions out there.

I understood 2% of that conversation-handling imposter syndrome when tech wont stop sprinting.

Ryan Kelly — Sat, 23 May 2026 19:44:49 +0000

Feeling Like an Imposter in Tech: Standing in Rooms Where Everyone Sounds Smarter Than You.

Or at least, smarter than you think you are.

There is a distinct feeling that comes with being a beginner in tech, and it usually starts quietly.

You walk into a room of developers, engineers, founders, or students who somehow already sound like seasoned professionals. Maybe it’s a tech meetup, a conference, a workshop, or a hackathon. Everyone seems to be speaking a language you should understand, but somehow don’t.

Someone says:

“We’re experimenting with multi-agent workflows and coding agents.”

Another person jumps in:

“Yeah, context windows still become a major bottleneck for large codebases.”

Someone else nods:

“The future is really about prompt engineering methods and orchestrations.”

And there you are. Smiling. Nodding. Quietly wondering: What on earth is happening?

This doesn't happen because you are lazy or incapable. It happens because somewhere between trying to master variables, APIs, Git conflicts, basic debugging, and just understanding how software works, the world suddenly moved into conversations about AI agents building systems autonomously. You are still trying to remember how to structure a clean, reusable function, and the room is already lightyears ahead.

If you have felt that exact tension, this article is for you.
The Silent Anxiety of Being "The Beginner in the Room"

As a student in tech, ambition can feel heavy. You have big dreams. You imagine building products, contributing to open source, becoming a great engineer, and maybe even launching something meaningful of your own.

Then you enter a room where professionals are discussing things that sound impossibly advanced, and suddenly, that ambition turns into comparison. You start asking yourself:

Will I ever get there?

Am I too late to the game?

How are people already talking about things I barely comprehend?

What if AI replaces the very skills I am burning midnight oil to learn?

Nobody says it out loud, but so many beginners experience this quiet panic. Especially now. Tech no longer feels like it is moving fast—it feels like it is sprinting. Yesterday you were learning HTML. Today people are debating AI copilots. Tomorrow someone writes an article claiming junior engineers may disappear entirely.

Your brain starts buffering like slow internet:
Plaintext

Loading confidence...
Error: self_doubt detected.

It’s funny, but it's painfully real.
The Conference Effect: Intellectually Underdressed

One thing I noticed after attending a few tech spaces is that people sound extremely confident. Sometimes, intimidatingly so. You hear a barrage of terms thrown around casually:

Multi-agent systems & LLM orchestration

Vector databases & CI/CD pipelines

Agentic engineering & Distributed systems

Context engineering

If you are still figuring out loops, state management, basic Git, or data structures, you begin feeling intellectually underdressed. You stop asking questions because you don't want to sound inexperienced. Instead, you become excellent at pretending. You nod. You laugh when everyone else laughs. You say things like, "Yeah, exactly," when internally you are thinking: I understood maybe 2% of that sentence.

The strange part? Many people in those rooms are confused too. They are just confused at different levels.

Tech has always worked like this. Someone always feels behind. Someone else feels overwhelmed. Someone else is pretending to understand Kubernetes. We are all somewhere on the ladder. The only difference is that experience changes what feels confusing, not the presence of confusion itself.
The Beginner Trap: Demanding Instant Mastery

One of the most important lessons I am learning is this: You are not supposed to understand everything immediately.

Seriously, think about how absurd the expectation is. You just started coding, and yet emotionally, you expect yourself to instantly grasp distributed systems, AI infrastructure, large-scale architecture, and production environments.

We treat our confusion like failure. But confusion isn't failure; it is usually the exact evidence that growth is happening. The moment you enter rooms where the conversations challenge you, you are no longer trapped inside the safety of what you already know. You are expanding—uncomfortably, slowly, but surely.
How AI Made the Imposter Feeling Worse

Let’s be honest: AI has completely shifted the experience of learning tech. Before, beginners worried about how to learn. Now, beginners worry about learning something that might become completely obsolete tomorrow.

You hear the doom-scrolling headlines every day: "AI writes code now." "Developers are turning into prompt engineers." "Agents can already build full apps."

Fear starts creeping in, and you begin asking: What exactly am I even learning this for?

But here is a perspective shift that really helped me: AI accelerates work, but it does not automatically replace understanding.

Consider this scenario: You ask an AI to solve a hard problem. The code looks great—until it breaks. Security issues pop up, project requirements change, weird edge cases emerge, or the performance becomes terrible. Suddenly, the generated code makes zero sense, and your AI assistant starts hallucinating.

This is exactly when deep, fundamental understanding matters. Software engineering is not just about raw code generation. It is about problem-solving, communication, understanding trade-offs, system architecture, debugging, and human judgment.

AI may help you move faster, but it does not magically grant you experience. You still need to learn the fundamentals.
The Hidden Truth About "Pros"

Here is something I wish beginners heard more often: Professionals also Google things constantly. Professionals also feel completely lost. Professionals also sit through tech talks thinking, I have absolutely no idea what this speaker is talking about.

The only difference between a senior engineer and a beginner is that the senior engineer became comfortable with not knowing.

That is the real skill in tech. It isn't total confidence; it’s comfort with uncertainty. Tech changes too fast for anyone to know everything. The people who survive are not the ones who hold all the answers—they are the ones who are willing to keep learning. Again. And again. And again.
What Is Helping Me Stop Feeling Like an Imposter

If you are struggling with this right now, here are four practical mindsets to anchor yourself:

Stop measuring your Chapter 1 against someone else's Chapter 20.

A senior engineer talking about complex codebases has already struggled through thousands of bugs, missed deadlines, terrible documentation, failed deployments, and years of deep confusion. You are seeing their experience compressed into confidence. It’s time, not magic.

Ask the "dumb" question.

One underrated realization I've had is that a confusing room instantly becomes clearer the moment one brave person speaks up and says, "Sorry, what exactly does that acronym mean?" You would be shocked by how many people in that room will silently sigh with relief because they wanted to ask the exact same thing.

Double down on the fundamentals anyway.

Yes, AI is evolving and things are moving fast. But fundamentals still compound. Variables, data structures, functions, algorithmic logic, network basics, and reading code—these things do not change. You grow in tech by learning the basics consistently, not by panicking over the latest framework trend.

Accept the awkwardness of growth.

Sometimes progress feels like awkwardness. Sometimes learning sounds like: "I have no idea what they mean right now, but I’ll figure it out later." That is not failure. That is active participation.

Maybe You Are Not an Imposter

Maybe you aren't a fraud at all. Maybe you are just early.

Maybe you are currently standing in rooms that your future self will feel completely comfortable managing. Today you understand 20%. Next year you'll understand 40%. Then, one day, someone sits down beside you at a meetup, hears a speaker, and whispers to you, "Hey, what are they talking about?"

And suddenly, you will be the one explaining it to them. Not because you became an overnight genius, but because you stayed. Because you kept showing up. Because confusion stopped scaring you.

Maybe that is what growth in tech really looks like. Not absolute certainty, but pure, stubborn persistence.

I'd love to hear from you: Have you ever walked into a tech space and felt completely lost? How are you balancing learning the fundamentals while trying to keep up with the breakneck speed of AI culture? Let’s talk about it in the comments below!

Learning Go Over Past Few Months

Ryan Kelly — Fri, 27 Mar 2026 10:35:11 +0000

From Hype to Harmony: Learning Go Over Past Few Months
Whenever someone would mention Go to me, I was always the brash guy asking why?. Another language? Over another thousand?! Well, now I’m a few months in and I can confidently say Go has been one of the most enjoyable (and sometimes painful) languages I’ve learned. Here’s a snippet of my experience.

The First Few Weeks
The first thing that took me aback about Go was its simplicity. No fighting semicolons for whom-alls. No wheel reinventions. No “here’s twenty ways to skin a cat” type BS. So I fired up my first Hello, World!, followed a few tutorials, and thought this is going to be easy but turns out i was wrong but in a good way

Finding Your Wall: Beginner Frustration
Go has a wonderful way of taking things that seem simple and making them feel difficult. It was important for me to realize Go is simple, but not easy.
The biggest issue I ran into was how Go handles errors. Coming from other languages, I figured there would be exceptions that I could deal with later. But Go likes to keep things honest. Here’s how errors are handled:
go result, err := somethingFn()
if err != nil {
// handle error here
}
This bothered me for far too long. I constantly felt like I was writing if err != nil more than actual code. Then one day it clicked — Go made me be comfortable handling failure, because I was literally handling it everywhere! You start to internalize your failure paths.

Channels as a Reinforcement Tool
If Go has one shining feature in my opinion, it’s goroutines. The barrier of entry to understand them and utilize them is so low. It took me a second to understand that in order to spin up a goroutine, all you do was:
go doSomething()
One single keyword. My life changed that day. I was writing a small script to ping some urls and in that moment I just decided “fuck it, I’m gonna do this concurrently”. No google, no tutorials. It was empowering.

Getting Stuck? Here’s What Still Stumps Me
The good news is I haven’t hit a wall lately. But there’s still things that catch me unexpectedly:

Pointers.Don’t Lie to Me.I get pointers. Conceptually, I understand them. It’s just deciding when to use them vs when to pass by value that trips me up occasionally.
Interfaces… am I implementing you?Go is weird about interfaces. They’re implicitly implemented, so understanding why something doesn’t implement an interface can send you down some weird rabbit holes.
I still don’t understand Go’s package system.I get it, I really do. It was just one of those “when do I use what” moments that took me a freaking week to learn importing because of Cannot Find Module.. errors.

What’s Next?
Having successfully navigated the initial deep-end, I’m now focused on a year-long intensive dive into Go and Git. The goal is no longer just "making it work"—it’s about mastery, scalability, and building tools that matter.

If you're thinking about starting your journey with Go, my advice is simple: Don't be afraid of the low-level stuff. It’s where the magic actually happens.

Are you learning Go too? I'd love to hear what tripped you up or what made it click — drop a comment below!

DEV Community: Ryan Kelly

Payment APIs, Decoded: The Architecture Behind Flutterwave, Paystack, PesaPal, IntaSend, and Stripe

1. What a Payment API Actually Is

Why payment APIs exist

The technical contract

2. Payment Processing Architecture

Breaking down each component

3. The Universal Integration Workflow

Why the secret key never leaves your server

Why step 11 (verification) is non-negotiable

4. Core Backend Concepts

Payment Initialization

Payment Verification

Webhooks

Authentication

PCI DSS

Tokenization

Payment States

5. Provider Deep Dives

Flutterwave

Paystack

PesaPal

IntaSend

Stripe

Technical architecture — the deepest of the five, deliberately

6. Flow Diagrams

Payment Request Flow

Webhook Flow

Refund Flow

Payout Flow (e.g., paying a creator/driver/vendor)

Subscription Flow (Stripe-style, conceptually generalizable)

Payment Verification Flow

8. Closing Thoughts

The Best Career Guidance Is a Tech Event You Didn't Want to Attend

Event 1: The Cursor × Claude Hackathon — The Day I Stopped Just Writing Code

Event 2: Nation.dev — The Uncomfortable Mirror

Event 3: Build From Here Conference — The Room Where They Told You the Truth.

Event 4: Africa Free Routing — Bitcoin, the Lightning Network, and Building for Your Continent

The Thread Connecting All Four

I Built a TCP Chat Server in Go Before I Understood Concurrency — Here's What Taught Me Goroutines, Channels, and Mutexes.

Where It Started

The First Question I Had to Answer

Concurrency Was Just a Buzzword Until This Project

What Is a Goroutine?

The Moment Goroutines Became Real

What Is a Channel?

How Channels Powered My Chat Rooms

The Bug That Taught Me About Blocking

Then I Met My First Race Condition

What Is a Mutex?

How Mutexes Saved My Hub

The Mental Model That Finally Clicked

The Hub: My Biggest Architectural Lesson

The Import Cycle That Taught Me About Package Design

Testing Changed How I Thought About Code

Concurrency Cheat Sheet

What I Know Now That I Didn't Know Then

Why Project-based learning works: How I Built a Live Platform while learning Go.

The Problem That Started Everything

Why Go? Why Learn While Building?

Month 1 — The Foundation (March 2026)

The First Go Program

Data Models and HTML Templates

SQLite and File Uploads

Offline by Design

Month2 - Polishing and improvements.

Dynamic Search and Filtering

Upvotes, Flash Messages, and LAN Deployment

Month 3 — Auth, Video, and Production (May 2026)

User Authentication in auth.go

Video Uploads and the 500 << 20 Idiom

Dockerization with Multi-Stage Builds

Database Migrations

The Infrastructure Stack

What Learning While Building Actually Looks Like

What's Live Today

What Comes Next

I understood 2% of that conversation-handling imposter syndrome when tech wont stop sprinting.

Learning Go Over Past Few Months

User Authentication in `auth.go`

Video Uploads and the `500 << 20` Idiom