DEV Community: Daniel Keya

From Beginner to Worker Pools: Mastering Golang Channels with Real Code Examples"

Daniel Keya — Tue, 17 Mar 2026 15:23:45 +0000

Go's concurrency model is one of its biggest selling points — and at the heart of it all are channels. Channels let goroutines communicate safely without shared memory, making concurrent code cleaner and easier to reason about.

In this post, we'll walk through the patterns in this open-source project that teaches Go channels from the ground up: starting with the basics, then moving into real-world patterns like worker pools, pipelines, and rate limiters.

What Are Go Channels?

A channel is a typed conduit through which you can send and receive values between goroutines.

ch := make(chan int)       // unbuffered channel
bch := make(chan int, 10)  // buffered channel (capacity 10)

Unbuffered: the sender blocks until the receiver is ready (synchronous).
Buffered: the sender only blocks when the buffer is full (asynchronous up to capacity).

Pattern 1 — Worker Pool (Fan-Out)

The worker pool is the most common real-world channel pattern. A single master goroutine generates tasks and sends them on a shared channel. Multiple worker goroutines compete to pick up tasks from that same channel — this is called fan-out.

How it works

Master ──► [task channel] ──► Worker 1
                          ──► Worker 2
                          ──► Worker 3
                               │
                               ▼
                        [results channel]
                               │
                               ▼
                           Collector

Code walkthrough

Task definition (task.go)

type Task struct {
    ID   int
    Data string
}

type Result struct {
    TaskID int
    Output string
}

Worker function

func worker(id int, tasks <-chan Task, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()
    for task := range tasks {
        // simulate work
        output := fmt.Sprintf("Worker %d processed task %d: %s", id, task.ID, task.Data)
        results <- Result{TaskID: task.ID, Output: output}
    }
}

Master (main.go)

func main() {
    const numWorkers = 3
    tasks := make(chan Task, 10)
    results := make(chan Result, 10)

    var wg sync.WaitGroup

    // Spin up workers
    for i := 1; i <= numWorkers; i++ {
        wg.Add(1)
        go worker(i, tasks, results, &wg)
    }

    // Send tasks
    go func() {
        for i := 1; i <= 9; i++ {
            tasks <- Task{ID: i, Data: fmt.Sprintf("data-%d", i)}
        }
        close(tasks) // signal workers no more tasks
    }()

    // Close results when all workers are done
    go func() {
        wg.Wait()
        close(results)
    }()

    // Collect results
    for r := range results {
        fmt.Println(r.Output)
    }
}

Key takeaways

close(tasks) is essential — it signals all workers that no more tasks are coming and they should exit their range loop.
sync.WaitGroup tracks when all workers have finished so you can safely close the results channel.
Tasks are automatically load-balanced: whichever worker is free picks up the next task.

🔗 Pattern 2 — Pipeline

A pipeline chains goroutines together so the output of one stage becomes the input of the next. Each stage runs concurrently.

Generate ──► Stage 1 ──► Stage 2 ──► Consume

func generate(nums ...int) <-chan int {
    out := make(chan int)
    go func() {
        for _, n := range nums {
            out <- n
        }
        close(out)
    }()
    return out
}

func square(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for n := range in {
            out <- n * n
        }
        close(out)
    }()
    return out
}

func main() {
    // Pipeline: generate → square → print
    c := generate(2, 3, 4, 5)
    out := square(c)

    for v := range out {
        fmt.Println(v) // 4, 9, 16, 25
    }
}

Each stage is a function that:

Receives a <-chan (read-only channel) as input.
Returns a <-chan as output.
Runs its own goroutine and closes its output channel when done.

This makes pipelines composable — you can chain as many stages as you like.

Pattern 3 — Rate Limiter

Rate limiters are critical in production systems — they prevent your service from overwhelming downstream APIs or databases.

Go's time.Tick combined with channels makes this beautifully simple:

func main() {
    requests := make(chan int, 5)
    for i := 1; i <= 5; i++ {
        requests <- i
    }
    close(requests)

    // Allow 1 request every 200ms
    limiter := time.Tick(200 * time.Millisecond)

    for req := range requests {
        <-limiter // block until the next tick
        fmt.Println("request", req, "processed at", time.Now())
    }
}

For bursty traffic (allow a burst then throttle), use a buffered ticker channel:

burstyLimiter := make(chan time.Time, 3)

// Pre-fill with 3 burst slots
for i := 0; i < 3; i++ {
    burstyLimiter <- time.Now()
}

// Refill at 1 per 200ms
go func() {
    for t := range time.Tick(200 * time.Millisecond) {
        burstyLimiter <- t
    }
}()

Common Pitfalls

Pitfall	What Happens	Fix
Forgetting `close(ch)`	Workers hang forever waiting	Always close the sender side
Closing a channel twice	Panic	Use a `sync.Once` or `defer` carefully
Sending to a closed channel	Panic	Ensure only the sender closes
Goroutine leak	Memory builds up silently	Use `context.Context` for cancellation

Running the Examples

Clone the repo and run any example:

git clone https://github.com/keyadaniel56/golang-channels
cd golang-channels

# Worker pool
cd project1-worker-pool-pattern
go run main.go task.go

# Pipeline
cd ../pipeline
go run main.go

# Rate limiter
cd ../rate-limiter
go run main.go

Summary

Pattern	Use Case
Worker Pool	CPU-bound tasks, parallel processing, job queues
Pipeline	ETL, stream processing, multi-stage transformation
Rate Limiter	API clients, database writes, external service calls

Channels are one of those features that take a little time to click — but once they do, you'll find yourself reaching for them constantly. The patterns in this repo are the building blocks behind real-world systems like message queues, web scrapers, and microservice workers.

⭐ If this was helpful, check out the full project on GitHub: golang-channels

Happy coding, and may your goroutines never leak! 🐹

Build a Real-Time Chat App with Go, Gin & WebSockets

Daniel Keya — Mon, 16 Mar 2026 11:55:35 +0000

Build a Real-Time Chat App with Go, Gin & WebSockets

WebSockets make real-time apps feel alive. In this tutorial we're going to build a fully functional multi-user chat app using Go, Gin, and Gorilla WebSocket — with sent/received message bubbles, a live online user counter, and a zero-dependency vanilla JS frontend.

The full source code is on GitHub: keyadaniel56/golang-chatapp

What We're Building

Multi-user real-time chat over WebSockets
Sent messages aligned right (yellow-green), received messages aligned left (teal)
Live "N ONLINE" counter in the header that updates instantly on join/leave
Join/leave system messages
A clean terminal-aesthetic dark UI — no frontend framework needed

Prerequisites

Go 1.22+
Basic familiarity with Go syntax
A terminal

Project Structure

golang-chatapp/
├── main.go          # All server logic
├── static/
│   └── index.html   # Frontend (vanilla JS)
├── go.mod
└── go.sum

Step 1 — Initialize the Module

mkdir golang-chatapp && cd golang-chatapp
go mod init chatapp
go get github.com/gin-gonic/gin
go get github.com/gorilla/websocket

Step 2 — The Message Type

Every piece of data flowing through the system is a Message:

type Message struct {
    Username  string `json:"username"`
    Text      string `json:"text"`
    Time      string `json:"time"`
    Type      string `json:"type"`       // "message" | "join" | "leave"
    UserCount int    `json:"user_count"` // set on join/leave events
}

The UserCount field lets the frontend update the online counter without a separate REST poll every time someone connects or disconnects.

Step 3 — The Client

Each browser tab that connects becomes a Client. It has two goroutines:

readPump — reads incoming JSON from the WebSocket and hands it off to the Hub
writePump — drains the send channel and writes JSON back to the browser

type Client struct {
    hub      *Hub
    conn     *websocket.Conn
    send     chan Message
    username string
}

func (c *Client) readPump() {
    defer func() {
        c.hub.unregister <- c
        c.conn.Close()
    }()
    for {
        var msg Message
        if err := c.conn.ReadJSON(&msg); err != nil {
            break
        }
        msg.Username = c.username
        msg.Type = "message"
        c.hub.broadcast <- msg
    }
}

func (c *Client) writePump() {
    defer c.conn.Close()
    for msg := range c.send {
        if err := c.conn.WriteJSON(msg); err != nil {
            break
        }
    }
}

When readPump exits (the browser closes or drops), it automatically fires unregister on the Hub — so the leave message and updated count get broadcast immediately.

Step 4 — The Hub

The Hub is the heart of the app. It runs in a single goroutine and is the only place that touches the clients map — no mutexes needed.

type Hub struct {
    clients    map[*Client]bool
    broadcast  chan Message
    register   chan *Client
    unregister chan *Client
}

func (h *Hub) run() {
    for {
        select {
        case client := <-h.register:
            h.clients[client] = true
            h.broadcastAll(Message{
                Username:  client.username,
                Text:      client.username + " joined the chat",
                Type:      "join",
                UserCount: len(h.clients),
            })

        case client := <-h.unregister:
            if _, ok := h.clients[client]; ok {
                delete(h.clients, client)
                close(client.send)
                h.broadcastAll(Message{
                    Username:  client.username,
                    Text:      client.username + " left the chat",
                    Type:      "leave",
                    UserCount: len(h.clients),
                })
            }

        case msg := <-h.broadcast:
            h.broadcastAll(msg)
        }
    }
}

func (h *Hub) broadcastAll(msg Message) {
    for client := range h.clients {
        select {
        case client.send <- msg:
        default:
            close(client.send)
            delete(h.clients, client)
        }
    }
}

Why no mutex? Because all reads and writes to h.clients happen inside the select statement in run(), which executes sequentially in one goroutine. The channels are the synchronization primitive.

Step 5 — Gin Routes

func main() {
    hub := newHub()
    go hub.run()

    r := gin.Default()

    r.Static("/static", "./static")
    r.GET("/", func(c *gin.Context) {
        c.File("./static/index.html")
    })

    r.GET("/ws", func(c *gin.Context) {
        username := c.Query("username")
        if username == "" {
            c.JSON(http.StatusBadRequest, gin.H{"error": "username required"})
            return
        }
        conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
        if err != nil { return }

        client := &Client{
            hub: hub, conn: conn,
            send: make(chan Message, 256),
            username: username,
        }
        hub.register <- client
        go client.writePump()
        go client.readPump()
    })

    r.GET("/api/users", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"online": len(hub.clients)})
    })

    r.Run(":8080")
}

Three routes:

/ — serves the frontend HTML
/ws?username=Alice — upgrades to WebSocket and registers the client
/api/users — returns the online count (used on initial page load)

Step 6 — The Frontend

The frontend is pure vanilla JS — no React, no Vue, just a WebSocket object and some DOM manipulation.

Connecting:

const proto = location.protocol === 'https:' ? 'wss' : 'ws';
ws = new WebSocket(`${proto}://${location.host}/ws?username=${encodeURIComponent(me)}`);

ws.onmessage = e => {
    const m = JSON.parse(e.data);
    if (m.type === 'join' || m.type === 'leave') {
        sysMsg(m.text, m.type);
        if (m.user_count !== undefined) setCount(m.user_count);
    } else {
        bubble(m);
    }
};

Rendering sent vs received bubbles:

function bubble(msg) {
    const isSelf = msg.username === me;
    const row = document.createElement('div');
    row.className = `bubble-row ${isSelf ? 'sent' : 'recv'}`;
    row.innerHTML = `
        <div class="dir-label">${isSelf ? '▲ SENT' : '▼ RECEIVED'}</div>
        <div class="bubble-meta">
            <span class="bubble-name">${esc(msg.username)}</span>
            <span class="bubble-time">${timestamp()}</span>
        </div>
        <div class="bubble">${esc(msg.text)}</div>`;
    append(row);
}

Sent messages (isSelf = true) align right with a yellow-green palette. Received messages align left with teal. The CSS does the heavy lifting:

.bubble-row.sent  { align-self: flex-end;  }
.bubble-row.recv  { align-self: flex-start; }

.bubble-row.sent  .bubble { background: #1a2604; border-color: #334d08; border-radius: 10px 2px 10px 10px; }
.bubble-row.recv  .bubble { background: #041a15; border-color: #0d3328; border-radius: 2px 10px 10px 10px; }

The asymmetric border radii (one sharp corner per bubble, on the side closest to the edge) are a subtle detail that makes sent vs received feel immediately distinct even without reading the label.

How It All Flows

Browser opens /ws?username=Alice
    → Gin upgrades to WebSocket
    → New Client created
    → hub.register ← client
    → Hub broadcasts join + user count to everyone
    → Frontend updates online counter

Alice types "hello"
    → ws.send({ text: "hello" })
    → Client.readPump reads it
    → hub.broadcast ← message
    → Hub loops all clients, pushes to send channels
    → Client.writePump writes JSON to each browser
    → Each browser renders bubble (sent=right / recv=left)

Alice closes tab
    → readPump exits, fires hub.unregister
    → Hub removes client, broadcasts leave + updated count

Running It

go mod tidy
go run main.go

Open two tabs at http://localhost:8080, enter different usernames, and start chatting. You'll see the online counter tick up to 2, and each tab will show its own messages on the right and the other person's messages on the left.

What to Build Next

Rooms/channels — add a room field to Message and maintain a map[string]*Hub
Persistence — write messages to PostgreSQL or Redis before broadcasting
Auth — validate a JWT in the /ws handler instead of accepting any ?username=
TLS — put Nginx in front and it will upgrade ws:// to wss:// automatically
Docker — the app is a single binary, a two-line Dockerfile is all you need

Source Code

GitHub: keyadaniel56/golang-chatapp

If this helped you, drop a ⭐ on the repo and share it with someone learning Go. Happy coding!

Building a Lightweight JWT Authentication Middleware for Go Gin Applications

Daniel Keya — Mon, 02 Feb 2026 21:41:46 +0000

Building a Lightweight JWT Authentication Middleware for Go Gin Applications

Authentication is the backbone of secure web applications. Today, we'll create a clean, production-ready JWT authentication middleware for Go applications using the Gin framework.

🎯 What We're Building

Our middleware will handle:

🔐 JWT token validation
📝 Bearer token support
👤 User context extraction
⚙️ Environment configuration
🧪 Comprehensive testing

🏗️ Project Setup

Let's start by setting up our project structure:

mkdir authmiddleware && cd authmiddleware
go mod init authmiddleware

Install dependencies:

go get github.com/gin-gonic/gin
go get github.com/golang-jwt/jwt/v5
go get github.com/joho/godotenv

📁 Project Structure

authmiddleware/
├── config/
│   └── config.go
├── middlewares/
│   └── authmiddleware.go
├── tests/
│   ├── auth_middleware_test.go
│   └── config_test.go
├── docs/
├── .env.example
├── go.mod
└── README.md

⚙️ Configuration Management

First, let's create our configuration handler in config/config.go:

package config

import (
    "log"
    "os"
    "github.com/joho/godotenv"
)

type Config struct {
    Port      string
    JWTSecret string
}

var AppConfig *Config

func LoadEnv() {
    err := godotenv.Load()
    if err != nil {
        log.Println("No .env file found, using system environment")
    }

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    AppConfig = &Config{
        Port:      port,
        JWTSecret: os.Getenv("JWT_SECRET"),
    }

    if AppConfig.JWTSecret == "" {
        log.Fatal("JWT_SECRET environment variable is required")
    }
}

🔐 The Authentication Middleware

Now for the main event - our JWT middleware in middlewares/authmiddleware.go:

package middlewares

import (
    "net/http"
    "os"
    "strings"

    "github.com/gin-gonic/gin"
    "github.com/golang-jwt/jwt/v5"
)

func AuthMiddleware() gin.HandlerFunc {
    return func(ctx *gin.Context) {
        // Extract token from Authorization header
        authHeader := ctx.GetHeader("Authorization")
        if authHeader == "" {
            ctx.JSON(http.StatusUnauthorized, gin.H{
                "error": "Authorization header is required"
            })
            ctx.Abort()
            return
        }

        // Handle both "Bearer token" and direct token formats
        tokenString := strings.TrimSpace(authHeader)
        if strings.HasPrefix(strings.ToLower(tokenString), "bearer ") {
            tokenString = strings.TrimSpace(tokenString[7:])
        }

        // Parse and validate JWT token
        token, err := jwt.Parse(tokenString, func(t *jwt.Token) (interface{}, error) {
            if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
                return nil, jwt.ErrSignatureInvalid
            }
            return []byte(os.Getenv("JWT_SECRET")), nil
        })

        if err != nil || !token.Valid {
            ctx.JSON(http.StatusUnauthorized, gin.H{
                "error": "Invalid or expired token"
            })
            ctx.Abort()
            return
        }

        // Extract claims and set context
        if claims, ok := token.Claims.(jwt.MapClaims); ok {
            ctx.Set("user_id", claims["user_id"])
            ctx.Set("email", claims["email"])
        }

        ctx.Next()
    }
}

🚀 Usage Example

Here's how to integrate the middleware into your application:

package main

import (
    "authmiddleware/config"
    "authmiddleware/middlewares"
    "github.com/gin-gonic/gin"
)

func main() {
    config.LoadEnv()

    r := gin.Default()

    // Public routes
    r.GET("/health", func(c *gin.Context) {
        c.JSON(200, gin.H{"status": "healthy"})
    })

    // Protected routes
    protected := r.Group("/api/v1")
    protected.Use(middlewares.AuthMiddleware())
    {
        protected.GET("/profile", getProfile)
        protected.POST("/data", postData)
    }

    r.Run(":" + config.AppConfig.Port)
}

func getProfile(c *gin.Context) {
    userID := c.GetString("user_id")
    email := c.GetString("email")

    c.JSON(200, gin.H{
        "user_id": userID,
        "email":   email,
        "message": "Profile retrieved successfully"
    })
}

🧪 Testing Our Middleware

Testing is crucial! Here's our test suite in tests/auth_middleware_test.go:

package tests

import (
    "net/http"
    "net/http/httptest"
    "os"
    "testing"
    "time"

    "authmiddleware/middlewares"
    "github.com/gin-gonic/gin"
    "github.com/golang-jwt/jwt/v5"
)

func TestMain(m *testing.M) {
    gin.SetMode(gin.TestMode)
    os.Setenv("JWT_SECRET", "test-secret-key")
    os.Exit(m.Run())
}

func createTestToken(userID, email string) string {
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
        "user_id": userID,
        "email":   email,
        "exp":     time.Now().Add(time.Hour).Unix(),
    })
    tokenString, _ := token.SignedString([]byte("test-secret-key"))
    return tokenString
}

func TestAuthMiddleware_ValidToken(t *testing.T) {
    router := gin.New()
    router.Use(middlewares.AuthMiddleware())
    router.GET("/test", func(c *gin.Context) {
        userID := c.GetString("user_id")
        email := c.GetString("email")
        c.JSON(200, gin.H{"user_id": userID, "email": email})
    })

    token := createTestToken("123", "test@example.com")
    req := httptest.NewRequest("GET", "/test", nil)
    req.Header.Set("Authorization", "Bearer "+token)

    w := httptest.NewRecorder()
    router.ServeHTTP(w, req)

    if w.Code != http.StatusOK {
        t.Errorf("Expected status 200, got %d", w.Code)
    }
}

func TestAuthMiddleware_MissingToken(t *testing.T) {
    router := gin.New()
    router.Use(middlewares.AuthMiddleware())
    router.GET("/test", func(c *gin.Context) {
        c.JSON(200, gin.H{"message": "success"})
    })

    req := httptest.NewRequest("GET", "/test", nil)
    w := httptest.NewRecorder()
    router.ServeHTTP(w, req)

    if w.Code != http.StatusUnauthorized {
        t.Errorf("Expected status 401, got %d", w.Code)
    }
}

🔒 Security Best Practices

When implementing JWT authentication:

Strong Secrets: Use cryptographically secure JWT secrets
Token Expiration: Always set expiration times
Signing Method Validation: Verify expected algorithms
HTTPS Only: Never transmit tokens over HTTP
Error Handling: Don't leak sensitive information

🏃‍♂️ Running Tests

Test your implementation:

# Run all tests
go test ./tests/...

# With coverage
go test -cover ./tests/...

# Verbose output
go test -v ./tests/...

📦 Environment Setup

Create .env.example:

PORT=8080
JWT_SECRET=your-super-secret-jwt-key-here

🎉 What We've Accomplished

Our middleware now provides:

✅ JWT token validation

✅ Flexible token format support

✅ User context extraction

✅ Comprehensive error handling

✅ Production-ready code

✅ Full test coverage

🚀 Next Steps

Consider extending with:

Role-based authorization
Token refresh mechanism
Rate limiting
Audit logging
Multi-tenant support

💡 Key Takeaways

Building your own auth middleware gives you:

Complete control over authentication flow
Better understanding of JWT security
Lightweight, dependency-minimal solution
Easy customization for business needs

📚 Source Code

🔗 Complete source code: GitHub Repository

⭐ Star the repo if this helped you! ⭐

What authentication challenges have you faced in your Go applications? Share your experiences in the comments below!

Connect with me:

🐙 GitHub: @keyadaniel56 - Follow for more Go tutorials!
💬 Let's discuss Go best practices and build amazing things together!

Found this helpful? Give it a ❤️ and share with fellow developers!

How to Integrate M-Pesa Daraja STK Push Using Golang

Daniel Keya — Wed, 28 Jan 2026 22:44:17 +0000

M-Pesa is the backbone of digital payments in Kenya, and Safaricom’s Daraja API makes it possible for developers to integrate M-Pesa services into their applications.

In this guide, we’ll implement Lipa na M-Pesa Online (STK Push) using Golang, covering authentication, payment initiation, and callback handling.

By the end of this article, you’ll be able to:

Authenticate with the Daraja API

Send an STK Push request

Handle payment callbacks from Safaricom

Prerequisites

Before you start, make sure you have:

Go installed (Go 1.20+ recommended)

A Daraja developer account

Sandbox credentials from the Daraja portal

Basic knowledge of Go and HTTP APIs

⚠️ Security Note
Never hardcode secrets in production. Always use environment variables.
Placeholders are used here for learning purposes.

Project Overview

The STK Push flow works as follows:

Obtain an OAuth access token from Daraja

Generate a password using Shortcode + Passkey + Timestamp

Send an STK Push request

Receive and process the callback from Safaricom

Configuration
package main

import (
    "bytes"
    "encoding/base64"
    "encoding/json"
    "fmt"
    "io"
    "log"
    "net/http"
    "time"
)

const (
    consumerKey    = "YOUR_CONSUMER_KEY"
    consumerSecret = "YOUR_CONSUMER_SECRET"

    shortcode = "174379" // Sandbox shortcode
    passkey   = "YOUR_PASSKEY"

    baseURL     = "https://sandbox.safaricom.co.ke"
    callbackURL = "https://your-public-url/mpesa/callback"
)

Step 1: Getting an OAuth Access Token

Daraja uses OAuth 2.0 for authentication.
We generate an access token using Basic Auth.


func getAccessToken() (string, error) {
    url := baseURL + "/oauth/v1/generate?grant_type=client_credentials"

    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return "", err
    }

    credentials := base64.StdEncoding.EncodeToString(
        []byte(consumerKey + ":" + consumerSecret),
    )
    req.Header.Add("Authorization", "Basic "+credentials)

    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    var tokenRes struct {
        AccessToken string `json:"access_token"`
    }

    if err := json.NewDecoder(resp.Body).Decode(&tokenRes); err != nil {
        return "", err
    }

    return tokenRes.AccessToken, nil
}

This token is required for all subsequent Daraja API requests.

Step 2: Sending an STK Push Request

To initiate a payment request, we generate a password using:

Base64Encode(Shortcode + Passkey + Timestamp)

func sendSTKPush(token string, amount int, phone string) error {
    timestamp := time.Now().Format("20060102150405")
    password := base64.StdEncoding.EncodeToString(
        []byte(shortcode + passkey + timestamp),
    )

    payload := map[string]interface{}{
        "BusinessShortCode": shortcode,
        "Password":          password,
        "Timestamp":         timestamp,
        "TransactionType":   "CustomerPayBillOnline",
        "Amount":            amount,
        "PartyA":            phone,
        "PartyB":            shortcode,
        "PhoneNumber":       phone,
        "CallBackURL":       callbackURL,
        "AccountReference":  "Ref123",
        "TransactionDesc":   "Test Payment",
    }

    jsonData, _ := json.Marshal(payload)

    req, _ := http.NewRequest(
        "POST",
        baseURL+"/mpesa/stkpush/v1/processrequest",
        bytes.NewBuffer(jsonData),
    )

    req.Header.Add("Authorization", "Bearer "+token)
    req.Header.Add("Content-Type", "application/json")

    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    return nil
}

go
Step 3: Handling the Callback

After the user completes (or cancels) the payment, Safaricom sends a callback to your endpoint.

func stkCallbackHandler(w http.ResponseWriter, r *http.Request) {
    var callback map[string]interface{}

    if err := json.NewDecoder(r.Body).Decode(&callback); err != nil {
        http.Error(w, "Invalid request", http.StatusBadRequest)
        return
    }

    log.Println("Callback received:", callback)

    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"ResultCode":0,"ResultDesc":"Received successfully"}`))
}

Callback Result Codes

ResultCode == 0 → Payment successful

Any other value → Payment failed or cancelled

To receive callbacks locally, expose your server using ngrok or Cloudflare Tunnel.

Step 4: Running the Application

📌 Phone numbers must be in the format 2547XXXXXXXX

```go{% embed %}
func main() {
http.HandleFunc("/mpesa/callback", stkCallbackHandler)

go func() {
    log.Println("Server running on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}()

token, err := getAccessToken()
if err != nil {
    log.Fatal(err)
}

sendSTKPush(token, 1, "2547XXXXXXXX")

select {}

}



Testing in the Sandbox

Use test phone numbers provided by Safaricom

Ensure your callback URL is publicly reachable

Check logs for successful callback responses

Security Best Practices

Store secrets in environment variables

Validate callback payloads

Persist transactions in a database

Always verify payment status before fulfilling orders

Conclusion

Integrating M-Pesa Daraja STK Push using Golang is straightforward once you understand the authentication flow, request structure, and callback handling.

With this setup, you can build:

E-commerce platforms

SaaS billing systems

Internal payment tools

If you found this useful, feel free to leave a comment or share 🚀