Expert Interview: Custom Software Solutions for Modern Merchants and Payment Technology

Today, we’re fortunate to interview Jaime Niswonger, Chief Technology Officer at Keyhole Software, a top-rated custom software development firm for mid-size to enterprise organizations across the United States. Keyhole specializes in custom application development and complex system integrations, including secure merchant and payment environments, working with experienced, U.S.-based senior developers who average 17+ years of professional experience.

At BAMS, we provide payment processing solutions that help merchants grow their businesses through reliable transaction processing, next-day funding, and chargeback management. Because payment technology increasingly requires custom software integration, we wanted to hear Keyhole’s perspective on how merchants can leverage technology to reduce fraud, improve customer experience, and build payment systems that scale.

Q: Jaime, what technologies are shaping the future of payment processing and merchant services?

A: From our perspective, the biggest shift isn’t a single technology, it’s the move toward more real-time, event-driven, and tightly integrated transaction platforms, with AI increasingly becoming part of the operational workflow around them.

In many of the environments we work in, payments are just one component of a broader ecosystem. They have to connect cleanly with customer systems, reporting, reconciliation, fraud and risk platforms, and downstream operational processes. So the conversations tend to be more about architecture: how to support faster processing, better visibility into transactions, and stronger security within existing enterprise environments.

AI is starting to play a role in how transaction data is analyzed and acted on, particularly in areas like anomaly detection, support workflows, and operational decisioning. In most cases, our work isn’t building those models, it’s making sure the surrounding systems can deliver clean, timely data to them and consume the results in a way that’s actionable and secure.

And as expectations around immediacy increase, the technical pressure moves to areas like messaging patterns, idempotency, observability, and fault tolerance. That’s where most of the real implementation effort tends to be.

So while there’s a lot of innovation in the payments space, the consistent challenge, and where we typically focus, is integrating these capabilities into complex, often legacy-heavy environments in a way that’s resilient, secure, and doesn’t interrupt the business.

Q: How can merchants use AI and machine learning to reduce payment fraud and chargebacks?

A: In the environments we’re typically working in, fraud reduction can end up being as much an architecture challenge as it is a data challenge. For merchants, that usually means the value from AI comes down to whether a real-time risk decision can be made inside the transaction flow rather than after it.

The models are evaluating a merchant’s historical patterns — how customers normally purchase, typical order values, device and session behavior, location changes, refund and dispute history. But those signals only matter if the surrounding systems can deliver that data consistently and act on the response immediately.

Where teams usually run into difficulty is integration. You’re connecting checkout, gateway, customer, and order systems that were never designed to participate in the same real-time decision, and the impact only shows up when that connection is reliable enough that the business can trust and automate the outcome.

Chargebacks follow the same pattern. The insight is already in the data, but the operational change happens when the original transaction, fulfillment details, customer activity, and the dispute workflow are tied together so responses can be generated consistently instead of handled manually.

So AI absolutely helps, but it reduces fraud and chargebacks only when it’s embedded directly into authorization and dispute handling. If it lives off to the side as reporting or a batch process, it produces useful signals. When it’s part of the transaction lifecycle, it changes the result.

Q: What custom technology do omnichannel retailers need to unify in-store and online payment experiences?

A: In most of the retail environments we’re brought into, unified commerce isn’t really a checkout problem. It’s a transaction and data consistency problem. What has to be true is that the payment, the inventory, and the customer record are all updated together no matter where the interaction starts. Otherwise, you don’t have a single experience, you just have different systems that all happen to take payments.

What that translates to in practice is a custom orchestration layer that can coordinate the transaction and keep those systems in sync in real time. A common approach is to bolt together different processors for store, online, and mobile, but that usually makes the data harder to trust, not easier to unify. Buy online and pick up in store is a good example. Inventory has to be reserved, the payment authorized, and availability updated at the same time, and most POS and e-commerce merchant account platforms were not designed to work that way.

Where it gets interesting is in the edge cases, things like sharing payment tokens across channels without adding new security overhead, dealing with partial authorizations when stock changes, or handling a return that starts in one channel and finishes in another. That is usually where the gaps show up.

In the platforms we have helped design and integrate, getting those flows right is what makes the experience feel unified to the customer. It is less about adding new checkout features and more about making sure every system involved in the transaction is working from the same real-time picture.

Q: What custom analytics and reporting tools help merchants make better data-driven decisions from transaction data?

A: Most processor reports are good at telling you what settled yesterday. What merchants actually need is a view of what is about to happen so they can make decisions about purchasing, staffing, and growth.

In practice, that usually means a custom data model and an integration layer that brings those sources together in a governed way. When transaction data is connected to the e-commerce platform, CRM, loyalty, and order systems, you can start to forecast deposits, understand true customer lifetime value, and see the real cost of accepting a payment. That includes chargebacks, fraud, and failed transactions, not just the processor fee.

Processors are designed for transactional reporting. They are not designed to answer merchant-specific questions. To do that, the data has to move across systems in a way that stays within PCI boundaries and updates quickly enough to be useful in day-to-day operations.

In the platforms we have helped design and integrate, that is what turns reporting into something the business can act on. You can see which payment methods actually produce the highest margin, how checkout changes affect authorization rates, and when cash is truly available to reinvest. Generic reports cannot do that because they do not understand how the rest of the business operates.

Q: How do businesses build secure, PCI-compliant payment systems and e-commerce platforms?

A: In most of the environments we work in, it really starts with architecture. The most important decision is keeping card data out of your environment as early as possible, which is why tokenization becomes the foundation of a PCI strategy. Instead of your application handling card numbers directly and pulling everything into scope, the payment fields are hosted by a PCI-compliant provider and only a token reaches your platform. That reduces the compliance burden while still letting you control the customer experience.

From there it becomes a question of boundaries. Payment processing has to be isolated from the rest of the system and every interaction with payment data needs to be auditable. Those patterns sound straightforward, but they are what determine whether you can deliver new features quickly or whether every change turns into a compliance exercise.

There is always a balance between security and agility. If the controls are too tight, the product stops evolving. If they are too loose, you run into audit issues. The processor is responsible for the acceptance and transmission of the payment, but the merchant is still responsible for how customer data is stored, how payment information is displayed, and how those APIs are integrated.

What we focus on is designing that boundary correctly from the beginning. With tokenization, secure integrations, and clear system segmentation in place, the platform can pass audits and still move at the pace the business needs. Those early decisions are usually what determine whether the system scales with the company or has to be reworked later.