NepalPay v1.2.1 — I Had the Same Bug in Six Files and Didn't Know It

v1.2.0 shipped Micrometer metrics and Spring Boot Actuator health indicators.

I was proud of it.

Then CodeRabbit reviewed the PR and found a security issue I had missed.

Then I fixed a bug in one file and realized the same bug existed in five other files.

Then I spent an afternoon fixing something that should have been a five-minute change but turned into a refactor.

That's v1.2.1.

The Bug I Had Six Times

Bug #13 was a file descriptor leak.

When ConnectIPS loads your .pfx certificate file at startup, it reads the bytes from disk.

The original code looked like this:

byte[] bytes = resource.getInputStream().readAllBytes();

That looks fine.

It isn't.

getInputStream() opens a FileInputStream.

readAllBytes() reads the bytes.

But nobody closes the stream.

On Kubernetes—where applications restart constantly during rolling deployments—each restart opened another FileInputStream and walked away.

Eventually the operating system refused to open any more.

java.io.IOException: Too many open files

The immediate fix was obvious:

try (InputStream stream = resource.getInputStream()) {

    byte[] bytes = stream.readAllBytes();

}

But when I went to apply that fix, I found the same implementation in six different places.

• 
  NepalPayAutoConfiguration.java (Boot 3)


• 
  NepalPayMetricsAutoConfiguration.java (Boot 3)


• 
  NepalPayAutoConfiguration.java (Boot 4)


• 
  NepalPayMetricsAutoConfiguration.java (Boot 4)


• NepalPayReactiveAutoConfiguration.java


• NepalPayReactiveMetricsAutoConfiguration.java

Six files.

Same implementation.

Same bug.

Six times.

That's a maintainability nightmare.

If I ever wanted to improve error handling, validate empty files, or change how .pfx files were loaded, I'd have to remember to update all six implementations.

So I stopped fixing the bug.

I fixed the architecture.

Introducing PfxLoader

I created a new utility in nepal-pay-core.

public final class PfxLoader {



    public static void validatePath(String pfxPath) { ... }



    public static byte[] read(InputStream inputStream, String pfxPath) {

        try (inputStream) {

            byte[] bytes = inputStream.readAllBytes();



            if (bytes.length == 0) {

                throw new ConnectIpsException(".pfx file is empty...");

            }



            return bytes;



        } catch (ConnectIpsException e) {

            throw e;

        } catch (Exception e) {

            throw new ConnectIpsException(

                "Failed to load .pfx...",

                e

            );

        }

    }

}

It lives inside nepal-pay-core, the only module with zero Spring dependencies.

Instead of accepting a Spring Resource, it simply accepts an InputStream.

The starter modules resolve the resource.

PfxLoader handles everything else.

Now every auto-configuration class simply delegates:

return PfxLoader.read(resource.getInputStream(), pfxPath);

One implementation.

One bug fix.

One place to maintain.

Issue #8 — The Timeout That Waited

Issue #8 had been open since before v1.1.0.

ConnectIPS configurable timeout

Every gateway supported configurable timeouts.

Except ConnectIPS.

Its timeout was hardcoded.

There's a reason the default isn't the same as Khalti.

Khalti and eSewa default to 10 seconds.

ConnectIPS defaults to 30 seconds.

Why?

Because ConnectIPS validates through Nepal Clearing House Ltd. (NCHL), which communicates with banking systems.

That introduces more network hops than a direct payment gateway API.

Banks can legitimately be slower during peak hours.

Reducing the timeout to ten seconds would create false timeout failures for perfectly valid transactions.

Instead, v1.2.1 keeps the default at 30 seconds while making it configurable.

nepalpay:

  connectips:

    timeout-seconds: 45

For the blocking starters, this configures both connection and read timeouts through SimpleClientHttpRequestFactory.

For the reactive starter, it configures Reactor Netty's responseTimeout() and TCP connection timeout.

Completely non-blocking.

Issue #8 closed.

The Security Issues CodeRabbit Found

After v1.2.0 shipped, I ran another CodeRabbit review.

It found two issues worth fixing immediately.

1. Timing-Safe HMAC Verification

The blocking Fonepay clients compared HMAC signatures like this:

if (!expected.equals(received)) {

    ...

}

String.equals() stops comparing as soon as it finds a mismatch.

That timing difference can theoretically leak information about the expected signature.

The reactive implementation already used a constant-time comparison.

The blocking implementations now do the same.

if (!MessageDigest.isEqual(expectedBytes, receivedBytes)) {

    ...

}

Both arrays are compared fully every time.

2. Logging Attacker-Controlled Data

During development I had added this debug log:

log.debug("decoded callback: {}", jsonString);

The decoded JSON ultimately comes from the eSewa redirect parameter.

That means it's attacker-controlled input.

Logging it verbatim isn't worth the risk.

The line is gone.

Instead, NepalPay logs only the signature verification result—information produced by the server itself rather than the incoming request.

The Documentation Got a New Look

This release wasn't only backend work.

The documentation site received a complete redesign.

The new Ocean theme includes:

• 🌊 Deep teal color palette


• ✨ Inter typography


• 💻 JetBrains Mono for code


• 🌙 Fully theme-aware light and dark modes


• 💾 Persistent theme selection

I also cleaned up several documentation issues:

• ConnectIPS timeout property documentation


• eSewa COMPLETE vs COMPLETED
  


• Fonepay PRN length constraints


• Builder reference improvements

Documentation deserves the same attention as code.

What's Coming in v1.3.0

The next milestone focuses on completeness rather than infrastructure.

Current roadmap:

• Webhook / Server-to-Server callback support


• eSewa Refund API (if eSewa publishes one)
  


• Kotlin examples (Issue #4)
  


• Small maintenance cleanups discovered during the v1.2.x cycle

Open source is never really finished.

Each release just solves the next problem.

Install

Spring Boot 3.2+

<dependency>

    <groupId>io.github.sujankim</groupId>

    <artifactId>nepal-pay-spring-boot-3-starter</artifactId>

    <version>1.2.1</version>

</dependency>

Spring Boot 4.x

<dependency>

    <groupId>io.github.sujankim</groupId>

    <artifactId>nepal-pay-spring-boot-4-starter</artifactId>

    <version>1.2.1</version>

</dependency>

Spring WebFlux Reactive

<dependency>

    <groupId>io.github.sujankim</groupId>

    <artifactId>nepal-pay-spring-boot-reactive-starter</artifactId>

    <version>1.2.1</version>

</dependency>

Learn More

GitHub

https://github.com/sujankim/nepal-pay-spring-boot-starter

Documentation

https://sujankim.github.io/nepal-pay-spring-boot-starter/

If NepalPay has saved you time integrating payment gateways into your Spring Boot applications, consider giving the project a ⭐ on GitHub.

It helps more developers discover the library and supports continued open-source development.

Found something broken?

Open an issue.

Want to contribute?

Issue #4 (Kotlin examples) is a great place to start.

Built with ❤️ for Nepal's developer community 🇳🇵