If you are a payment provider, you have probably come across the fact that the same transaction can behave completely differently depending on whether the card is "familiar" to the system or appears for the first time. In some cases, it goes through the first time, in others it gets rejected, and in others it can even ruin the channel's statistics.

Why is this happening and is there any way to control it? May.

Imagine: a transaction enters the system, and you, as a provider— must decide which acquiring channel to send it to. If the card has already been successfully used before, this is one scenario. If it 's new, it's completely different.

It is important for the provider to understand:

Have you already made successful payments with this card or not?

Has it been used in other projects in the system?

Have there been refunds or chargebacks?

The answers to these questions directly affect conversion rates, rejection codes, and even the health of acquiring channels.

Yes. At eComCharge, we have developed a tool that solves this problem — Smart Check.

It allows you to “get acquainted” with the card before you send it somewhere. The service analyzes whether the card has been in the system before, how many successful/unsuccessful transactions it has, and what types of transactions. Based on this data, you can set your own routing conditions.

For example:

If there have been 3 successful payments and one successful payout on the card in the last 180 days, we consider the card “verified” and send the transaction to a more sensitive but profitable channel.

Smart Check doesn't make decisions for you — it just provides verified data that can be used in routing rules. This works especially effectively in systems where Smart logic is already configured. Routing.

This functionality is necessary for any PSP that manages multiple channels and wants to optimize traffic. But it is especially relevant for those who:

• works with unstable or “new” traffic,
• accepts clients in high-risk verticals (iGaming, Forex, adult, etc.),
• collides with with the rapid increase in refusals for new cards,
• builds flexible routes depending on the history of the map.

In fact, Smart Check becomes a reference point for making decisions: whether to skip the card further or not, which channel to send it to, and whether to test a new route.

Smart Check collects data on all transactions involving the card and stores them in the beGateway system. Moreover , they are taken into account:

• authorizations,
• payments,
• payments,
• refunds,
• chargebacks,
• P2P transfers etc.

For each type, the number of successful and unsuccessful operations for a given period (up to 360 days) is saved. These counters can be used in routing conditions and combined with each other.

In this case, the provider can choose:

• use only your own data (local database),
• or connect a global database (data from all providers in the beGateway system) — this is especially convenient if the card has already been in circulation.

The service is activated upon request and configured individually for each store. In other words, you can enable Smart Check only where it is really needed.

For me, Smart Check is about conscious traffic management. It's about the ability not just to accept transactions “blindly”, but to understand what you're working with. Especially in business, where every mistake in the route can be expensive — literally.

If you are developing a payment platform or building a PSP , I recommend that you think about using such tools from the very beginning. This will help you not only save money, but also scale without unnecessary stress.

If you are interested in how this is implemented in eComCharge , I will be happy to tell you in more detail. And if you are already working with beGateway, it is possible that Smart Check is already collecting data for you — it just remains to include them in the rules.

The article was written using news from the company's website ecomcharge.com