Payments used to be a separate job, done in a separate place: a bank portal, a card terminal, a processor's dashboard. Increasingly they are a step inside the software a business already uses, and the latest sign came on 26 October, when Mastercard and Tech Mahindra announced a partnership to build business-to-business payments into enterprise software.
The convenience is real. It also raises two questions that the announcements tend to leave out. When the payment is invisible, does the business on the receiving end still know who is providing the service? And who owns that relationship?
What was announced
The two companies plan to embed Mastercard's virtual card and payment capabilities in the enterprise resource planning (ERP) and procurement platforms that large companies use to run their purchasing and finance. A virtual card is a card number generated for a payment or a supplier, usually with limits on amount and use, and with no plastic behind it.
Mastercard brings the payment capabilities and its virtual card network. Tech Mahindra brings the integration work, connecting them to systems a company already runs so that it does not have to replace them. The promised results are familiar ones: automated supplier payments, real-time reconciliation, spend controls, fraud management and better use of working capital. In the words of Roshan Shetty of Tech Mahindra, the aim is "bringing payments directly into the flow of procurement and finance".
This is an announced partnership, not a live service with results. It names no customers, volumes or launch dates, so its significance lies in the direction it points to.
Two things called embedded payments
The term covers two different arrangements, and the question of who owns the relationship has a different answer in each.
| Paying out | Taking payment | |
|---|---|---|
| Who uses it | A company paying its suppliers | A business selling to its customers |
| Where it sits | ERP, procurement and accounts payable software | Booking, ecommerce and industry software |
| Who chooses the payment method | Usually the buyer | The software vendor, often by default |
| Who the "merchant" is | The supplier receiving the card | The software vendor's own customer |
The Mastercard and Tech Mahindra announcement is the first kind. That matters, because the supplier is the merchant in this arrangement and it does not choose the software. Its customer does.
What it means for a supplier
A supplier paid by virtual card is accepting a card payment, and accepting a card has a price. The cost normally falls on the supplier, as a merchant discount that is mostly interchange. One card programme provider, Corpay, says as much in its own guide, and notes that smaller suppliers on thin margins may resist it. Some programmes hand part of the buyer's rebate to the supplier to soften the fee.
A supplier invited into a buyer's programme should therefore treat it as a commercial decision, even when it arrives looking like an administrative one. Ask what the payment will cost after every fee, whether the supplier's own acquirer will process it, whether earlier payment is part of the bargain, and whether another payment method remains available.
There is also a case where the supplier does not accept cards at all and an intermediary does so on its behalf. Visa's rules recognise this as a Business Payment Solution Provider: it contracts with the acquirer, the buyer pays it by card and the underlying biller does not accept Visa. Visa does not allow the model for a biller that accepts Visa through another channel.
Who is actually providing the service
Embedding does not reduce the number of companies involved. It adds some and hides them behind one screen. For any single payment, several parties may be doing different jobs:
- The software vendor owns the screen and the customer's daily attention.
- The integrator connects the systems and may have no part in the payment itself.
- The card scheme sets the rules and runs the network.
- The issuer provides the buyer's card.
- The acquirer is the regulated party that accepts the payment on the merchant's side, and it holds the scheme relationship.
- A payment facilitator, if there is one, signs the merchant up on the acquirer's behalf and may receive the settlement.
The logo on the screen may belong to any of these or to none of them. The party that can hold your money, close your account or impose a reserve is often not the one whose name you see every day.
Who owns the relationship
For a business taking payments, the answer comes down to who holds the contract. Using Visa's rules as the reference, since Mastercard sets its own:
| Model | Who you contract with | What the customer sees | Your position |
|---|---|---|---|
| Your own merchant account | Your acquirer or provider | Your name | The account is yours, and so is the work of underwriting and integration |
| Payment facilitator | The facilitator, which must hold a merchant agreement with you | The facilitator's name and yours | Quick to start, on terms set for many businesses |
| Marketplace | The marketplace, which contracts with the acquirer in place of its sellers | The marketplace's name and yours | The marketplace issues the receipt and handles refunds and disputes |
| Merchant of record | The company that sells to the customer in its own name | Usually that company | The least work and the least control. The term has no single definition, so read the contract |
Size can change the position. Under Visa's rules, an acquirer working with a payment facilitator must sign a direct merchant agreement with a sponsored merchant that exceeds USD 1 million in annual volume. There are exceptions, including where the facilitator has held the relationship for two years with the same acquirer and reports on it regularly, and a business can therefore pass the threshold and stay where it is.
Liability is the part that does not move out of sight. Visa holds the acquirer liable for the acts of a payment facilitator and its sponsored merchants, and a sponsored merchant is treated as a merchant of that acquirer. So however smooth the sign-up, someone is carrying the risk and will want to underwrite it.
When embedded is the right answer
None of this is an argument against embedded payments. For a new or small business, a payment option that works on the day the software is installed can be far better than months of applications. One contract, one support line and one reconciled set of records have real value, and for a low-risk business selling in one country they may be all it needs.
The risk is in choosing without noticing. An embedded option is often accepted as part of buying the software, by someone evaluating the software, and its pricing, reserve terms and exit terms get less scrutiny than a provider chosen on its own would. That choice can become expensive later, when volumes grow, the business enters a new country or moves into a category the platform does not want.
Questions to ask before you accept
Before switching on a payment option inside any software, get written answers to these:
- Who is my contract with? Name the legal entity, and the acquirer behind it.
- Whose name will my customers see? On the receipt, on the card statement and in any dispute.
- Who holds my money? How long settlement takes, and whether a reserve can be imposed. Our article on rolling reserves explains how they work.
- Who can close the account, and on what notice? If the payment account closes, ask what happens to the software you depend on.
- Who handles disputes? Disputes still count, and our article on chargebacks sets out why the ratio matters.
- What does it really cost? Ask for the full fee, and whether the software vendor earns a share of it.
- What am I classified as? A platform will assign a merchant category code, and the wrong one causes trouble later.
- Can I use another provider alongside it? Some software ties its features to its own payment option.
- What can I take with me? Stored cards especially. If they sit with the platform in a form only it can use, leaving means asking every customer to enter them again. Our article on running more than one provider covers why that matters.
What it means for providers and ISOs
When payments are sold inside software, the first sale is often to the software vendor, and a provider can lose direct contact with the businesses it serves. The vendor becomes the channel and, in practice, the party that decides which provider its customers meet.
That does not remove the need for underwriting. It raises the importance of knowing what is coming through the channel, since the liability stays with the acquirer however easy the sign-up feels. It also leaves a real opening. The businesses that outgrow an embedded option, sit outside a platform's appetite or need a specialist still have to find a provider.
Invisible payments, visible choices
Payments may well become invisible to the person making them. The choice of provider does not go away. It moves earlier, and often to someone else: to the software vendor that picked the partner, or to the buyer that set up the programme.
So the question for any business is whether it made that choice deliberately. That means knowing who provides its payment services, what they offer and what the commercial model is, before the convenient option becomes the only one.
How Payments Marketplace can help
Payments Marketplace does not process payments. It helps a business see which providers suit it before it commits. Its free pre-flight check scores your business against each provider's underwriting rules, so you can weigh an embedded option against the providers whose criteria you meet.
You can then send an anonymised application to the provider you choose. It sees no name or contact details until it accepts, and a match is an introduction, not an approval: the provider still decides. Providers receive applications already screened against their criteria, with the merchant's identity withheld until they accept.
Merchants can run the free pre-flight check. Providers can read how it works for providers.