A simple pricing update or equipment change shouldn’t require a flurry of emails, support tickets, and manual intervention. Yet for independent software vendors (ISVs) managing merchant operations, these routine tasks can quickly become complicated.
As their merchant portfolios grow, so does the complexity. Account information scattered across multiple portals and dashboards makes it harder to keep operations running smoothly and respond quickly to merchant needs. Merchant management APIs bring key account functions—including updates to merchant details, pricing, and equipment—into a payment provider’s own systems, reducing reliance on manual processes and disconnected portals.
In a recent PaymentsJournal podcast, North’s Bryan Long, Senior Director of Product Management, and Brad Staudt, VP of Partner Sales, along with Don Apgar, Director of Merchant Payments at Javelin Strategy & Research, discussed how this technology enables merchant payments providers to manage customer accounts directly within their own systems.
Merchant management APIs can reduce manual processes and consolidate fragmented systems while helping providers differentiate themselves where it matters most: the merchant experience.
An API-Driven Advantage
Historically, merchant account management has relied on emails, support tickets, manual updates, and handoffs. These processes slow responses to changes in customer status and disputes, with fragmented systems adding further complexity.
“The first thing that comes to my mind is the phrase, ‘Dashboards are dead,’” Apgar said. “The last thing that clients want is another dashboard to log in and view data and download data and export data. What companies need to be truly efficient is a way to consume data.”
Merchant management APIs address these challenges by providing a centralized platform for managing merchant portfolios beyond onboarding.
This includes merchant status, business details, contacts, equipment, and pricing. Partners with appropriate permissions can update this information through the API, eliminating the need to navigate separate processes for routine changes.
The API also give partners the ability to build their own merchant and agent dashboards using these account details. Webhooks can notify payment provider when a merchant’s status changes or a new dispute arises, allowing them to respond promptly.
Together, these capabilities connect previously fragmented aspects of merchant management. By integrating account management and dispute-related functions into their software, providers can reduce the need for merchants to switch between portals.
“With this product, partners can control their own user interface and they own the user experience, while North provides the back end and the connection to card brands,” Long said. “This is especially powerful for larger partner types like wholesale independent sales organizations (ISOs) or full-service providers (FSPs) who manage risk and underwriting for their merchants.”
“It transforms merchant operations into an automated API-driven competitive advantage for our partners,” he said.
Accommodating Distinct Partner Profiles
One of the platform’s defining features is its flexibility. Retail ISOs, wholesale ISOs, ISVs, and full-service providers (FSPs) have distinct operational needs, even as the lines between these business models continue to blur.
“The line between ISO and ISV is disappearing, it’s almost gone, frankly,” Apgar said. “But one of the powerful things of the ISV is being able to provide that completely turnkey embedded experience for the merchant. Being able to accept payments through the software is part A. Part B is being able to automate that whole reconciliation, settlement, and fee allocation process.”
“By being able to consume data through an API right into the ISV’s platform, it makes the whole payments experience completely embedded and turnkey for the merchant,” he said. “That’s a differentiating factor for the ISV.”
To accommodate these differences, the merchant management API offers customizable access based on a partner’s role and requirements.
For example, retail ISOs and ISVs that build point-of-sale systems may need only read-only access, as they typically do not assume financial liability for merchants. This access allows them to incorporate information such as chargeback data, alerts, and equipment status notifications into their own software-as-a-service (SaaS) dashboards without granting broader permissions to sensitive account functions.
However, the API is not a one-size-fits-all solution. Some ISVs may require write access to specific endpoints, depending on their contractual arrangements. An ISV, for instance, might want to manage the full chargeback lifecycle within its own user interface.
For these partners, the API provides granular access controls that allow write permissions where appropriate.
“On the side of the partnership agreements like wholesale ISOs and FSPs, they have full write access,” Long said. “When these partners are managing the risk, they’re managing the underwriting, and they’re managing merchant pricing, they’re getting the full write access.”
“They can programmatically update bank accounts, they can change fee schedules, they can adjust terminal parameters, and handle dispute rebuttals directly through the API,” he said. “In effect, they own the user interface, but it’s powered by our back-end system.”
Scaling Across Business Models
These granular capabilities can deliver value on their own, but the merchant management API offers another important advantage: scalability.
“Many legacy processors have multiple platforms and say, ‘Retail platform, we’re going to put you on our Stargate platform and when you grow up, we’re going to put you on our Gemini platform,’” Apgar said. “It creates barriers to growth for the client because as they try to take their business to the next level, part of that is now a systems conversion onto some other core platform.”
Whether a partner starts with read-only or write access, the platform provides a unified foundation that can accommodate changing business needs. An organization that begins as a retail ISO with read-only privileges can later transition to a wholesale ISO or FSP model and obtain additional write permissions as needed.
This flexibility is particularly relevant as organizations evolve. Wholesale ISOs, FSPs, and retail ISOs often maintain technology relationships with multiple partners for a variety of reasons. A platform that can accommodate different business models and access requirements may help simplify these relationships and support growth.
“It’s all about control at the end of the day,” Staudt said. “That’s the evolution—going from an agent to an ISO to a wholesale ISO, maybe an FSP—and not one path is right for everyone. From an FSP standpoint, everything changes. It’s not just about signing merchants; it’s being responsible for those merchants. To do that, you need the data quickly and that’s what this does.”
Evaluating the Move to Full-Service Provider
For organizations considering a transition to the FSP model, several factors warrant careful consideration.
“Typically, companies think FSPs are cheaper, but the reality is you have much more overhead in terms of how you’re managing underwriting, you’re managing risk, you’re dealing with settlement and your sponsor bank,” Staudt said. “It’s so much more than just signing up accounts. You have to ensure that you have enough volume to justify bringing all those people on board and managing the business.”
Although the cost structure and greater control associated with becoming an FSP can be attractive, the transition also brings additional responsibilities and expenses. Rather than basing the decision primarily on pricing, organizations should evaluate the implications for control, risk, and liability, including the costs and requirements associated with PCI compliance, sponsor banks, and bank identification numbers (BIN).
“As a wholesale ISO, North would be a party to the agreement, it’s one of our sponsor banks,” Staudt said. “With the FSP, we’re not a party to the merchant agreement. You’ve brought your own sponsor banks to the situation, but you also have the cost associated with having a BIN.”
“We do dedicated, shared BINs for wholesale ISOs and then FSP is strictly dedicated BINs,” he said. “They’re all things to consider when deciding whether you want to go down the wholesale ISO or FSP pathway.”
Expanding the Developer Experience
The complexity of merchant operations underscores the need for more integrated management tools. But as the merchant payments space evolves, so do the capabilities providers need to support their partners.
New developments include broader webhook integration and the introduction of ACH dual pricing for embedded checkout, which is designed to encourage customers to pay by bank transfer rather than card.
North, an early developer of merchant management API capabilities, is continuing to build on this foundation by reimagining its developer portal to meet the needs of the evolving merchant payments ecosystem.
“It will be built for two integrators: the developer and the AI agent coding alongside them,” Long said. “This will include rolling out an MCP server, llms.txt, and a robust feature set so that LLMs can access our docs and our code samples and our integration guides through an interface that’s designed for them, as opposed to the current interface, which is obviously designed for humans.”
“We’re also continuously expanding and improving our developer experience,” he said. “That looks like more self-service capabilities on the product roadmap that we’ve published publicly. We’re also digitizing and automating the partner application process. You can get your agent ID a lot quicker digitally.”