Three sides of the rails.

Most people in payments specialise on one side of the rails for their whole career. They get good at it. They build a network in it. They learn the vocabulary, the personalities, the regulatory texture. After a while it becomes the only way they can think about payments, and the other sides become a sort of distant rumour. The acquirers think the issuers are slow. The issuers think the acquirers do not understand risk. The orchestration people think everyone else is making the same problem harder than it needs to be. Each side is right about one thing and wrong about two.

I have been a senior Customer Success and Relationship person on all three sides now. Worldpay and FIS on the acquiring side, where the customer is a merchant and the deliverable is acceptance. APEXX Global in the orchestration layer, where the customer is also a merchant but the deliverable is choice, routing and consolidation. And now Enfuce on the issuing and processing side, where the customer is a fintech or bank and the deliverable is a card programme.

The titles are similar. The work is not. Here is what each one actually feels like from inside the seat, and what that means for anyone hiring CS in payments or moving between sides.

01. Acquiring: time is the product

In acquiring, the customer is processing real transactions, often at enormous volume, and every single one of them is on a clock. A decline that takes four seconds to come back is a different commercial problem to one that comes back in four hundred milliseconds, even if it declines either way. A reconciliation file that arrives twelve hours late is somebody's payroll problem. A scheme fee adjustment in Mastercard's quarterly release is a finance director's spreadsheet problem within a week.

The CS role on this side is mostly about turning the relentless, slightly chaotic flow of payments operations into something the customer can hold in their hands. Quarterly business reviews become anchored in real numbers: auth rates by issuer, decline reasons broken down by code, fraud ratios trending up or down, cross-border volumes, settlement timings. The conversation is almost always quantitative because the data exists and the customer cares about it in cash terms.

What makes acquiring CS distinctive is that you are usually one of several people the customer talks to at the acquirer. There is an account director on the sales side, a technical account manager on the integration side, an operations contact for the daily grind, a scheme team for chargebacks, and you. The customer has to figure out which of you to call about what, and your job is largely to make sure the answer is "you, first." If they have to navigate the org chart to get a question answered, you have not done your job.

The hardest part is keeping perspective on what is genuinely the customer's problem and what is just operational noise. A merchant with £500m of processed volume will have something going wrong every single day. The skill is knowing which two of the fifteen things this week actually need to surface at executive level, and which thirteen can be quietly resolved without ever appearing in a deck.

02. Orchestration: choice is the product

Orchestration is a different animal entirely. The customer is still a merchant, often a sophisticated one running multiple acquirers, but what you are selling them is not acceptance. It is choice. Routing logic. The ability to consolidate. The promise that they no longer have to integrate with three more payment service providers next year, because you have already done it for them.

The commercial conversation shifts from "are we processing your payments well" to "are we processing your payments better than the status quo." Better can mean cheaper, because you are routing to the acquirer with the best rate for that specific bin range. Better can mean higher-converting, because you are sending the transaction through whichever processor has the best auth rate for that customer's profile right now. Better can mean simpler, because the merchant's finance team no longer has to reconcile across four different reporting platforms.

The CS role here is unusually consultative. You are constantly testing hypotheses with the customer. If we route this volume through acquirer A instead of B for the next thirty days, what happens to conversion? If we add this alternative payment method to the checkout, what happens to total revenue? You become part-analyst, part-strategist, part-account-manager. The QBR is less about reporting on the past month and more about the experiment you are going to run together next month.

The trap in orchestration is that you can spend a lot of time optimising things that only matter in aggregate. A 0.3% auth rate uplift sounds boring until you multiply it by the customer's annual processed volume and realise you have just earned them seven figures. The customer might not even notice unless you are the one drawing the line between the change and the number. That line-drawing is the job.

03. Issuing and processing: the long arc

On the issuing side the customer is a fundamentally different beast. Instead of an established merchant with existing volume, you are often working with a fintech that is launching, or a bank that is migrating, or a brand that is putting cards in the hands of its customers for the first time. The product is not acceptance or routing. It is the card programme itself, and everything that hangs off it: BIN sponsorship, scheme certification, the lifecycle of every issued card, regulatory and compliance overhead, integration with the customer's onboarding and ledger and authorisation systems.

Time horizons are longer. An acquiring customer might churn or grow in a quarter. An issuing customer is often a multi-year programme before it really hits its stride, because launching a card programme is a substantial undertaking. You are not optimising performance month-on-month. You are co-managing a roadmap, sometimes literally presenting jointly to the customer's board, because their card product is now structurally dependent on yours.

This makes the CS role on the issuing side feel closer to the role of a long-term programme manager than a quarterly account relationship. The day-to-day is full of decisions that will matter in two years: which scheme to certify under, how to structure the hierarchy, what the disaster-recovery plan looks like, how the customer wants their statements to read, whether they want their cards to support tap-to-mobile-wallet from day one or as a later release. None of these are dramatic individually. Cumulatively they decide whether the programme is a success.

The other distinctive thing about issuing CS is the regulatory weight. You are constantly working alongside compliance, financial crime, risk and legal teams in a way that acquiring rarely demands. An acquiring CSM might go a quarter without a serious compliance conversation. An issuing CSM has compliance somewhere in the room almost every week.

04. So what differs, beyond the obvious

At surface level, the three sides differ in who the customer is, what the product is, and what the time horizon looks like. Below the surface, the differences are more interesting.

Where the conversation lives. Acquiring CS lives at operations and finance level. Orchestration CS lives at strategy and growth level. Issuing CS lives at product and programme level. None of these are wrong; they just dictate which of the customer's executives you naturally end up closest to. A CSM who came up through acquiring and lands in issuing has to learn how to talk to a product manager. A CSM who came up through issuing and lands in acquiring has to learn how to talk to a finance director.

What good looks like. In acquiring, success looks like fewer fires per week. In orchestration, it looks like a chart going up and to the right. In issuing, it looks like a programme launching on time and growing in volume after launch. The metric changes, the cadence changes, the celebration changes.

Where the failure modes are. An acquiring CSM fails by missing operational signal. An orchestration CSM fails by not running enough experiments. An issuing CSM fails by losing command of the long timeline. These are genuinely different competencies and you cannot fully prepare for one by being good at another.

Most people in payments specialise on one side because the depth required is real. But it is worth knowing that what feels like the whole job from inside one side is, from another side, only the beginning of the job.

05. The unfair advantage of having done all three

I am not going to pretend it is some kind of superpower. The acquiring specialist with twenty years on the same side will know things about chargeback codes and scheme rules that I will never catch up on. The same is true the other way. You give up depth for breadth.

But there is a particular kind of customer conversation that gets unlocked. The merchant who is about to launch a card programme of their own. The orchestration customer who wants to understand why one of their acquirers is suddenly showing different auth characteristics. The issuer who is trying to decide whether to offer their cards through a marketplace platform. These conversations involve all three sides of the rails simultaneously, and being able to hold all three in your head, even imperfectly, changes the quality of the advice you can give.

The other unfair advantage is taxonomical. When a customer describes a problem, you can usually tell within thirty seconds which side of the rails the actual issue lives on, regardless of which side the customer thinks it lives on. A merchant who is complaining about an acquiring decline rate might really have an issuer-side problem with their card design choices. An orchestration customer who is complaining about poor routing might really have an acquiring-side problem with one of their providers. Knowing which side to look at shortens the diagnostic cycle considerably.

06. If you are choosing which side to work on

My genuine recommendation, if you are early in a payments CS career and have any choice in the matter, is to spend at least one serious chapter on each side. Two or three years apiece if you can. You will be a more rounded CS person at the end of it than you would be by doubling down on one side from the start.

But if you are choosing one to commit to, the deciding question is about temperament. Are you energised by the daily flow of operational data and the cadence of fires-to-fix? Acquiring. Are you energised by experimentation and the slow optimisation of complex systems? Orchestration. Are you energised by building long programmes alongside customers and seeing the slow arc bend over years? Issuing.

Any of the three is a real career. None of them is the version of Customer Success you read about on the internet. That is fine. Payments at the enterprise end has always been a quieter and weirder industry than the SaaS world it sits next to. The CS role in it reflects that, on whichever side of the rails you happen to pick.