52. Super Wrappers

Let me bring back one of my favourite toys — Russian Nesting Dolls… why favourite? I am too old to play with them and my daughter is too bored of them… but Matryoshka Dolls / Russian Nesting Dolls are a perfect analogy for India’s payment ecosystem… I am sure that previously I have referred to them, multiple times, throughout this blog. So why again?

Because today, I will write about wrappers or super wrappers… Although my focus will be on the payment gateway side, I would still briefly touch upon a few interesting cases from other areas of payment/FinTech. So let’s start the ‘unwrapping’.

Revisiting Basics:

You are a merchant and you want to enable different payment options (CC, DC, NB, wallets, UPI etc.) and there are various ways you can do it — two of the most common methods are:

A. Payment Aggregator (PA)

By doing one integration with a payment aggregator, the merchant can enable various payment modes and receive one single settlement. The merchant can use the card vault of the payment aggregator to save cards.

Illustration 1: Single Aggregator

But the method has certain drawbacks

• Merchant is dependent on one provider: if aggregator is down, then merchant is blank and puts a pause to his business
• Not all modes may be available (few banks or wallets may be missing)
• Not all features available (e.g. Deep linking of the wallet)
• Lock in with one aggregator if you have vaulted cards with that aggregator

There is a simple way to address issues of dependency, payment coverage, features or even commercials. i.e. add another payment aggregator who can provide solutions to these

Illustration 2

But this method brings few new problems

• Integration effort: Integrating new PA, designing checkout page, building a centralised dashboard for ops and analytics, disjointed user experience as customers might see different Payment pages at different times based on the PA chosen.
• Maintenance effort: Managing routing logics, monitoring two dashboards/reports to analyse performance
• Operation Effort: Additional settlement for new PA that increases reconciliation and refund efforts

If the volumes are high enough, then the merchant can take up these additional activities.

But still the question remains: How do you provide a uniform ‘save card’ option?

There are some crude ways to manage the card vault: E.g.: if the user’s mobile number is ‘even’ then use PA 1 and if ‘odd’ then use PA2. So you will vault cards in respective PAs. Or another crude way is if credit card, then vault with PA 1 and if debit card, then vault of PA2.

As I said, these are crude methods and not scalable models but one of the biggest DTH providers followed this kind of method for years… so it is possible.

B. Hybrid Model

Bigger merchants do not just rely on payment aggregators but also do direct integration with acquiring banks (card/UPI), net-banking banks (big ones) and wallets.

Illustration 3

This model allows the merchant to manage performance, enable unique features (e.g. linking wallet), commercials and payment provider/bank offers. But the merchant has to live with few drawbacks (multiple settlements, multiple dashboards, managing routing logics and more importantly, integration effort).

Even if a merchant is ready to take up these efforts, there is still one big problem: how to provide a uniform save card function?

As I said earlier, payments are like Russian Nesting Dolls…here comes the outermost doll — Super Wrapper or TSP (Technology Service Provider).

What is a Super-Wrapper?

Super-Wrapper/TSPs are the entities that provide a single integration platform and all leading PAs, Acquiring Banks, large banks, wallets, pay later products etc. are readily integrated.

The merchant has to do one time integration with the wrapper. A typical wrapper will provide,

• PCI Compliant card vault (so no lock-in with any PAs)
• Enable/Disable PA, banks, payment providers
• Routing engine: . Most wrappers give out of the box solutions (so merchants don’t have to build it) to divert and split traffic across multiple PA/PGs based on Merchant’s preference.
• Unified dashboard: check performance & success rate of all payment providers in a single place and also helps to remove the need of building an internal ops dashboard for payment ops.

Then how are they different than payment aggregators:

• Wrapper can bring multiple competing PAs on a single platform
• A typical wrapper doesn’t do settlements: settlement will be done directly by the payment service provider or PA to the merchant

Players:

• JusPay: The most known player in this business — completely (almost) PA/PSP agnostic player. Also, offers additional products including mobile SDK to optimise bank pages and auto-reading OTP. (Ref: Website)
• DreamPay: Subsidiary of Dream11 and planning to hit the market soon (Ref: Website)
• Pine Labs, RazorPay, Ingenico, PayU, PayTM — These PAs also have some sort of wrapper with limited PAs. And mostly created to counter JusPay.

Note 1: Think of it, a payment aggregator is a wrapper with settlement capabilities, as a PA brings multiple payment options with a single integration. There are many use cases, where a PA also works like a pure wrapper while the bank provides the TID/MID and does settlement but the aggregator only processes the transaction.

Note 2: A Payment Aggregator’s super wrapper will not succeed as much as that of JusPay or DreamPay, as a competing PA will not be happy that its data is going via another PA’s systems. So the success of a super wrapper depends on ‘neutrality’.

Commercial Models:

A typical wrapper will have charges that are different than that of a PA or PG. As this is nothing but a SaaS model and there is no back-to-back cost with banks/PAs, they can be flexible and creative in terms of pricing.

• % (Percentage) of the transaction value
• Fixed fee per transaction
• Monthly fixed fee
• Additional charges of card vault etc.

A typical PA deducts the charges from a merchant or customer (except for a few sectors where invoicing is done e.g. Mutual Funds). A PA can do it as it does the settlement (read here). But a super wrapper who is not doing settlement doesn’t have channels to deduct charges, so they have to work on an invoicing model. And the problem with invoicing is that ‘people never pay back on time’

Drawbacks, Limitation & Considerations:

• All eggs in one basket: A wrapper can still become a single point of failure for the merchant
• Operations: A wrapper may take care of card vault and integration problems but still the merchant has to manage the reconciliation work. More PSP/PAs, more settlement and thus more operation work (Few of these Wrappers — JusPay, DreamPay offer Recon product as well)
• Charges: Along with PA/payment providers, merchant has to bear additional charges of the super wrapper

Considerations:

All said and done, do you really need a super wrapper? Definitely there are positives but, there are negatives as well. So as a merchant, I would consider the below points:

• Card vault: Do I really need to provide a ‘save card’ feature? If yes, then can I simply take PCI compliance instead of using a wrapper (Build Vs.Buy decision).
• Payment Options: Do you really need to add a lot of PAs and payment providers? If my present PA is not offering few tail-end banks for net-banking then do I need to bring a new PA if volumes are negligible from those banks.
• Platform Capability: Merchant can very well put some effort into integrating new PAs and develop internal dashboards to view performance and also manage routing. Does it make sense to buy these capabilities from a wrapper or build in-house?
• Cost optimisation: Even if you are adding a wrapper but does it make sense to pay on each payment mode when value is less. E.g. A wrapper has great value for card vault but what is the value when it comes to net-banking. If SBI NB website is down, then it doesn’t matter which aggregator you use to process that transaction. So do I need a wrapper on all modes or only selected mode so the cost can be optimised?
• All Eggs in one basket: As highlighted earlier, a super wrapper becomes your single point of failure. So you would still need a back-up (hope for the best and plan for the worst). Hence, keep a few modes outside the wrapper (e.g. wallets and NB where a super wrapper doesn’t add much value)

Other Super Wrapper Payment Products:

Super wrappers are not new. As I said earlier, some of the PAs are acting like semi-super-wrapper for ages. But these days, you would notice the super wrapper or TSP are quite common across other products also. Entire open banking concept is based on wrappers where one entity is offering services of multiple banks without being banks.

Payouts: As covered in Article 49 (Payouts — Basics Revised), a connected integration with the bank for payout is nothing but a wrapper/TSP model. Even JusPay and Recko are also providing payout wrappers

BBPS: For decades, BillDesk has been acting as a TSP/wrapper for banks to enable EBPP and then later BBPS. But the scope was limited to one bank at a time. But Setu.co pushed the concept further by becoming a super wrapper (with settlement capabilities) for BBPS with multiple banks

There is no silver bullet (single solution) for solving a merchant’s payment requirements. And as long as there are gaps, one or other company will try to come up with a solution. Thus, keep adding more layers/dolls to our Russian Nesting dolls.