What embedding payments actually asks of a software platform

What actually changes for the platform

Three things move, and they move at different speeds.

The sign-up flow changes first. Payments cannot be switched on by ticking a box. A business has to be onboarded: company details, ultimate beneficial ownership, proof of bank account, and verification against the acquirer's requirements. That process has to live somewhere in the product, and the natural place is inside the existing sign-up journey rather than bolted on beside it. This is a product design decision as much as a technical one.

Reporting changes second. Once a merchant is taking payments through the platform, they expect to see them there. Settlement reports, transaction detail and dispute status become things the platform either surfaces or fields questions about. Surfacing them is more work up front and considerably less work afterwards.

Support changes third, and this is the one that surprises people. Payment questions do not go to the payments provider. They go to whoever sold the software. A merchant whose settlement is short does not know, and should not need to know, which of four companies in the chain caused it. They call the name on the invoice.

What the platform becomes responsible for

Under a payment facilitator model, the regulatory weight stays with the facilitator. The operational weight is shared, and the split is worth being precise about.

• Selling payments to the merchant: the platform.
• Agreeing commercial terms with the merchant: the platform.
• Collecting onboarding information: the platform, through the product.
• Verifying the business and its owners: the facilitator.
• Opening the merchant account with the acquirer: the facilitator.
• First-line merchant support: the platform.
• Settling funds to the merchant: the facilitator.
• Managing chargebacks and deadlines: the facilitator.
• Supplying dispute evidence: the platform, via the merchant.
• Regulatory authorisation and safeguarding: the facilitator.
• Card scheme compliance: the facilitator.

The pattern is consistent. The platform owns the relationship and everything the relationship touches. The facilitator owns the money, the regulator and the acquirer.

The trade-off nobody puts in the pitch

Embedding payments makes the platform more valuable to its merchants and harder to leave. It also makes the platform accountable for something it does not directly control.

When a settlement is late, the platform did not cause it and cannot fix it directly, but the platform takes the call. When onboarding stalls because a document was unclear, the merchant's frustration lands with the platform. When a chargeback deadline passes without evidence, the merchant lost the money and the platform gets the conversation.

This is not a reason to avoid embedding payments. It is a reason to plan for it. Platforms that go in expecting a revenue line and nothing else tend to be surprised twice: once by the support volume in the first six months, and once by how much of it was avoidable with better onboarding design and better reporting.

The platforms that do this well treat payments as a product surface rather than a partnership. They build the onboarding into the sign-up flow properly, they surface settlement data inside the product, and they train their support team on the first two lines of every payment question so that only genuine escalations leave the building.

What genuinely stays off the platform's plate

It is worth being equally clear about what does not change, because the regulatory burden is the thing platforms most often overestimate.

The platform does not need FCA authorisation to resell payments under a facilitator. It does not carry the safeguarding obligation for merchant funds. It does not hold merchant money at any point. It does not need to become a card scheme member, maintain the acquiring relationship, or take on PCI DSS responsibility at the level a direct arrangement would require.

Those are substantial obligations, and a platform taking them on directly is choosing to become a payments company. Some do, deliberately, with the capital and compliance function to match. Most vertical software companies are better served by the software they already build.

What to establish before committing

Questions worth asking any payments partner, and worth asking about any model rather than any brand.

• On onboarding. What information is required, in what order, and what typically causes an application to stall? Can it be completed inside our product or does the merchant leave to finish it elsewhere?
• On settlement. What determines the timetable? What happens when a settlement does not complete on the scheduled day? What reporting do we get, and can we pass it through to the merchant directly?
• On disputes. Who tells us a chargeback has been raised, and how quickly? What is the evidence deadline? Who chases the merchant?
• On support. What questions can our team answer, what needs escalating, and what response times apply? What documentation exists for our support staff rather than for merchants?
• On the merchant relationship. Does the payments provider ever contact our merchants directly? Under what circumstances? This one matters more than it sounds, and the answer tells you what kind of partnership you are entering.
• On exit. If we move, what happens to our merchants' merchant accounts and settlement history?

Frequently asked questions

Do we need to be FCA authorised to offer payments to our customers? Not under a payment facilitator model. The facilitator holds the authorisation and carries the regulatory obligations. A platform choosing to hold merchant funds or contract directly with an acquirer is in different territory and should take its own advice.

How long does it take to embed payments? It depends on how much of the onboarding and reporting experience is built into the product rather than handed off. The integration work is usually the smaller part. The product design around it is the larger part.

Can we keep our existing payment arrangements for some merchants? Usually yes. Platforms often run a transition rather than a switch, with new merchants onboarded to the new arrangement while existing ones continue as they are.

What happens to our merchant relationships? Under a facilitator model they stay with the platform. The platform sells, sets the commercial terms and remains the first point of contact. The facilitator operates behind it.

What is the most common thing platforms underestimate? Support volume in the first six months, and how much of it comes from reconciliation questions that better reporting would have answered.

Embedding payments changes what a platform is responsible for, not just what it earns. The platforms that plan for the second part tend to be the ones that are still happy with the decision two years later.

VestaOne works as the payment facilitator behind software platforms across education, hospitality, retail, catering and sport, running onboarding, settlement, disputes and compliance so the platform keeps the merchant relationship and the product roadmap.

VestaOne is a trading brand of Vesta Merchant Services Limited, registered in England and Wales, company number 07108015. Vesta Merchant Services Limited is authorised by the Financial Conduct Authority as a payment institution, firm reference number 784165. Part of Vesta Software Group.

This article is provided for general information only. It is not financial, legal or regulatory advice, and it does not take account of any particular business's circumstances.