For a company that sells across borders, cards sit at both ends of the business. You spend on one side — travel, software, suppliers — and you accept payments on the other. Getting both without a local entity in every market is where most operators lose time.

Spending: corporate cards

The spending side is often the first international need. A small team wants cards that work in several countries, in several currencies, with limits that reflect policy rather than guesswork. Inside SUPA, cards are provided through licensed partners, which means the card rails are established ones and the unit supplies the structure around them: limits, approved counterparties and approval thresholds applied below the model, where an agent cannot argue with them. Every card use is recorded against the unit, the principal and the policy version it belongs to.

Accepting: card acceptance

The accepting side raises a different question. A business that wants to take card payments in a new market would normally need to consider a local entity and a local acquirer. Reaching a market through hub participants and rails is the alternative SUPA is built for. Card acceptance is arranged through licensed partners, while the unit keeps the reporting and document trail in one place. You are not required to stand up a subsidiary in each country simply to be able to charge a customer there.

Why the partner model matters

Card products are regulated, and SUPA is explicit about this: it is not yet a bank, it does not hold client money in its own name before it holds a banking licence, and balances sit with licensed partners. Working through licensed partners for cards and acquiring is what allows the perimeter to stay simple without pretending the regulation away. Local-law limits are checked per jurisdiction, and cross-border reliance is not permitted everywhere.

This is general information, not legal, tax or financial advice.

In short:

  • Cards for spending and acceptance are both part of a unit.
  • Card products come through licensed partners.
  • Cards and acceptance work without a local entity in every market.
  • Policy limits apply below the model, and every use is recorded.

Run cards and acceptance from one perimeter: business.