What are on-us transactions?

Simply put, on-us is when both the card issuing bank (the one who issued the card to the customer) and the acquiring bank (the one who processes the payment) are in the same system or even the same bank. Example:

• A customer has a Bank A card (issuer).
• And your store is connected to Bank A acquiring directly.
• Result: the payment remains "in-system" - an on-us transaction.

Why is this good?

• Less chance of rejection - antifraud and risk algorithms are "more loyal" to your own.
• Minimal fees - no interbank acquiring.
• Instant payments - less hops, less delays.
• Reliability - fewer third-party systems, fewer points of failure.

How to build on-us acquiring?

Conventional acquiring: you agree with one bank - it is both the acquirer and the issuer of a number of cards. But this is almost always a compromise:

• Convenient for that bank's customers.
• Inconvenient for everyone else.

The way of the star: Have multiple accounts at popular banks - e.g:

• Bank A
• Bank B
• Bank C
• Bank D

And route transactions depending on the client's card. A client has a Bank A card - we make the payment through your acquiring in Bank A. Another has a Bank B card - we make the payment to Bank B.

Where is PayStar.uk?

PayStar.uk is neither a bank nor an aggregator. It's a payment platform and router that combines your entire payment infrastructure into one flexible interface.

What it provides:

1. Routing by BIN's - we identify the customer's bank by card number and route the payment to where there is a higher chance of successful on-us.
2. Multi-acquiring support - you can connect as many banks and payment systems as you like.
3. Flexible rules - routes by country, currency, amount, card type, time of day, status of previous attempt.
4. Acustom payment page - white-label design where the customer won't even know the payment has gone through complex architecture.
5. Ready ecosystem of integration - PayStar.uk is already connected to many e-commerce platforms: Shopify, WooCommerce, OpenCart, Bitrix, as well as to acquiring major banks. This allows you to launch in literally a day or two.

Example of architecture

1. Your online store is connected to the PayStar.uk API.
2. You have merchant accounts in:
   • Bank A - for customers with Bank A cards.
   • Bank B - for cards from Bank B.
   • Bank C - as a fallback acquirer.
3. PayStar.uk receives the request, identifies the bank by BIN-code.
4. Sends the transaction through the necessary channel - priority on-us.
5. If the bank does not respond, cascade routing is activated and the payment goes to another channel.
6. Acustom payment page - white-label design where the customer won't even know the payment has gone through complex architecture.
7. Ready ecosystem of integration - PayStar.uk is already connected to many e-commerce platforms: Shopify, WooCommerce, OpenCart, Bitrix, as well as to acquiring major banks. This allows you to launch in literally a day or two.

Result:

• Conversion > 95%.
• Faster authorization
• Fewer rejections and chargebacks
• Commission optimization
• Increased resilience - one bank goes down, the system switches to another automatically

Security and stability

PayStar.uk runs on a distributed server architecture and guarantees:

• Uptime 99.5%+ - officially spelled out in license agreements;
• 2FA and IP whitelist for API keys;
• Secure communication channels (SSL/TLS) at all layers;
• Data isolation between clients.

What you need to get up and running

• Merchant accounts with multiple banks.
• Registration and license with PayStar.
• Routing setup (on your own or through support).
• A/B testing of schemes and optimization based on analytics.

Conclusion

On-us acquiring is not a marketing gimmick but a technical advantage. Previously, only banks could afford it. Now it's any e-commerce project.

With PayStar.uk, you can turn your payment schemes into a smart, adaptive, fail-safe mechanism that not only saves on fees, but also raises conversion to a new level.

A payment shouldn't just be possible. It should be as successful as possible.