Building a Go Payment API Library From Scratch

Collins Kipruto — Thu, 09 Jul 2026 13:03:30 +0000

description:

Insights on pointers, methods, resource management, and HTTP clients while building an open-source Go library.

tags:

golang, backend, webdev, learning

A few days ago, a couple of friends and I decided to take a detour from our usual routines to build something practical: a Go library for payment APIs.

The goal is simple. Instead of every Go developer writing custom, repetitive code to integrate payment gateways, they can just import our open-source library straight from GitHub.

Building a library forces you to think deeply about architecture, developer experience, and language fundamentals. Here is everything this project has taught me so far.

1. Client Structure and a Sharper Grip on Pointers

Setting up the base client structure required a lot of intentional data modeling. In doing so, I gained a much clearer understanding of pointers in Go. Deciding when to pass a struct by value versus passing a pointer to mutating states is a critical choice when designing an API client that other developers will rely on.

2. Deconstructing the Authentication Flow

Implementing authentication gave me a front-row seat to the full request-response lifecycle. I broke down the exact steps needed to establish a secure connection:

URL Construction: Building clean, dynamic endpoints.
Request Creation: Preparing payloads and setting secure headers.
Validation: Verifying our data before it leaves the application.
Transmission & Response: Sending the request to the admin server and handling the incoming payload cleanly.

3. Functions vs. Methods: The Concrete Difference

While the terms are often used interchangeably in other languages, Go draws a distinct line between functions and methods.

A Function is a standalone block of code used to execute a program routine.
A Method is simply a function that contains a receiver, meaning it belongs to a specific type.

// This is a standalone function
func ClearCache() {
    // logic here
}

// This is a method belonging to the 'User' struct type
func (u *User) DeactivateAccount() {
    // logic here
}

4. Resource Management: Why You Must `defer Body.Close()`

One of the biggest gotchas for newer Go developers is resource leakage via HTTP responses. When you make a network request, the server keeps the connection open until you explicitly close it.

Using defer response.Body.Close() right after checking for errors is mandatory.

Think of it like borrowing a book from a library. If you keep borrowing books and never return them, your state keeps looping on "borrowing." Eventually, the library runs out of space, and you cannot borrow anymore. In Go, failing to close the body will cause your application to run out of memory and file descriptors.

5. Staying Flexible with `http.Client.Do()`

When interacting with different payment endpoints, you encounter various HTTP verbs like POST, GET, PUT, and DELETE.

Instead of wrapping our client in strict, specialized helpers, we relied on Go's native http.Client.Do() method. Because .Do() accepts a completely custom *http.Request object, it accommodates any HTTP method seamlessly. If an upstream payment provider suddenly changes a route from a POST to a PUT, our underlying architecture remains intact and resilient.

Wrapping Up

This project is turning out to be an amazing engineering journey. By building this library, I am moving past just "using" payment APIs to truly understanding how they function under the hood.

I'll be sharing more updates as my team moves closer to our alpha release. If you have any tips on building clean SDKs in Go, let me know in the comments below!

What I Learned Building My First Go Project (go-reloaded)

Collins Kipruto — Wed, 17 Jun 2026 09:42:25 +0000

During my first week at Zone01 Kisumu, I worked on a project called go-reloaded. It was my first real hands-on experience using Go, and it helped me understand not just the language, but also how to think like a developer.

In this article, I’ll share what I learned, the challenges I faced, and the key concepts that made everything click.

What the Project Was About

The goal of the project was to build a small Go program that works with command-line arguments and processes input using Go’s standard libraries.

This was my first time interacting deeply with:

os package
command-line arguments (os.Args)
basic Go program structure

At first, it felt confusing, but step by step, things started to make sense.

What I Learned

How command-line arguments work in Go I learned that Go provides access to raw input from the terminal using: os.Args

This returns a slice of strings where:
os.Args[0] is the program name
os.Args[1:] are the actual inputs

Working with the os package The os package became one of the most important parts of the project.

I used it to:
Read input arguments
Handle program execution flow
Understand how programs interact with the system

This helped me realize that Go is very close to the system level compared to JavaScript.

Breaking problems into smaller steps One of the biggest lessons wasn’t about code—it was about thinking. Instead of trying to solve everything at once, I learned to:

Understand the problem first
Break it into smaller tasks
Solve each part step by step

This made debugging much easier.

Challenges I Faced

At the beginning, I struggled with:

Understanding how os.Args works
Knowing where to start in the code
Handling errors when inputs were missing

Sometimes I would get stuck just trying to figure out what the program was actually receiving.

But debugging helped me a lot. Printing values at each step made things clearer.

Key Takeaways

Go is very explicit compared to JavaScript
The os package is powerful for system-level interaction
Command-line arguments are simple but very useful
Problem-solving is more important than syntax
Debugging is part of learning, not a failure

Final Thoughts

This project was a big step in my learning journey. It helped me understand how Go works and how to approach programming problems more effectively.

I’m still learning, but each project is making things clearer.

Next, I’m looking forward to building more complex projects and improving my backend and DevOps skills.

DEV Community: Collins Kipruto