Your website runs fine, but next to it sits a Java program that handles card transactions with Taiwan's National Credit Card Center (NCCC).

The integration library or SDK you were given back then was in Java, so building a separate program for it was perfectly reasonable.

The trouble usually comes a few years later: the program is still running, but nobody dares touch it anymore.

These scenes may be familiar

The engineer who wrote it has left, and no documentation was left behind
An NCCC specification change notice arrives, and nobody knows which part to change
A certificate is about to expire, and nobody notices until card payments fail
You want to redesign the website, but any change near checkout raises the fear that cards will stop working
Website orders and payment records don't reconcile, so you check them one by one

How many apply? The real problem is usually not Java — it is that this part has become a black box.

A different language really isn't the problem

A website and a payment program written in different languages is not a problem in itself, and it does not mean something has to be rewritten.

What needs sorting out is this:

Clear boundaries: the payment program handles transactions; orders, discounts and stock stay with the website
A written interface: what data is sent, how long before timeout, and whether failures can be retried
Keys and certificates with an owner: where they live, when they expire, who renews them
A test process you can run end to end: authorisation, cancellation, refunds and every flow you actually use
Someone who knows when things go wrong: when the service fails, the system notices and users see the correct status
A process for changes: when a spec change arrives, you can quickly judge its impact and how to make the change

Once these are in place, the program nobody could touch starts becoming manageable.

How tenet-O can help

If you also have a card-payment integration left over from years ago, we start by sorting out the existing system rather than telling you to rewrite everything.

Understand it first: map how the existing program, the website and the payment flow connect
Write it down: document the interface, configuration, certificates, deployment and error handling
Add checks: set up the tests and reconciliation you need, so changes don't only reveal problems after something breaks
Then decide how to change it: keep maintaining it, refactor part of it, or genuinely rebuild — decide once you can see clearly

You don't necessarily need a rewrite, or a new payment provider.

Often the first step is simply bringing that program everyone knows is important, but nobody dares touch, back into clear view.

Another common case is routine work held together by Excel and manual checks:

Managing a Stack of FCNs and Fighting Excel After Every Close?

Is there a Java program like this behind your website too?

Talk to tenet-O →