15. Integration — Final Notes

We touched upon important aspects of the integration, so before you start the integration finalise,

A. Payment Page:

We have already covered different types of payment pages and pros & cons of those. So depending on your use case, decide on payment page either redirection page, iFrame or seamless flow

B. Payment coverage:

How many aggregators, acquiring banks, wallets you need to have optimal payment method coverage. Do not add a payment method just because it is available in market.

Example: If you are an e-commerce merchant with low ticket size then you won’t need EMI on cards but if you are selling airline tickets then EMI will be good sales booster.

Note: Every time you add in new payment provider that mean you will get additional settlement report and your finance team will not be happy about it.

C. Payment Flow Flavours:

In transaction section, we touched upon various flavours of card, wallet transactions. So decide on payment flows needed

• For Cards: Standard card flow or direct OTP flow or Debit Card ATM PIN flow
• In case of wallets, standard re-direction flow or link & Pay flow

Multiple flow means, you should be ready to do multiple integrations and also, cleverly manage those flows

D. API Needed:

Check on APIs required to be implemented that fits your payment page strategy

• For ‘redirection page’, merchant has to implement minimal APIs
• For ‘seamless flow’ and ‘card vault’, merchant has to implement additional APIs such as Transaction with add card, transaction without adding card, transaction using stored card

APIs of different aggregators, payment providers have different parameters, some are mandatory and some are optional. So are the response codes and error codes. So need to have capability to handle all API calls uniformly.

Note: Alternatively use TSP who can provide or develop such payment platform (E.g. JusPay)

E. Card vault strategy:

Do you want to save card and with whom (self, aggregator, TSP).

If you have already vaulted cards with aggregator then plan your next step because you may have to face lot of resistance and it is time consuming process

• Migration to your own vault, another aggregator or TSP
• Start afresh (check total vaulted cards, active users and expired cards and decide whether want to migrate or start afresh)
• Use aggregator A to process already saved cards and save new cards to your own vault or TSP’s vault

F. Routing Logics:

Set your objective and define the routing logic accordingly (covered in last section). Keep fine tuning the routing logic till you consistently achieve better results

G. Checkout Flow:

• Think of overall checkout experience that should be frictionless in terms positioning of payment methods and shouldn’t confuse customer.
• If adding coupons then make sure coupons are easily accessible as part of the flow

I. Operations:

a. Settlement Reconciliation: Every new payment service provider will give you new set of settlement file. So more the payment providers then more files. You finance team will not be happy handling so many files. Think of automating settlement reconciliation

b. Refund Management: More payment providers and more complex routing means, you need capability to remember through which payment provider transaction is done and you need to mark refunds against same payment provider.

c. Dashboards: Every payment service provider will give a dashboard. So if you have 5 payment service providers then you will end up looking at 5 dashboard. So think of unifying dashboard.

d. Keep an eye on operations: Adding and removing payment aggregator (service provider) is common practice but here are some points that you need to consider before plug off payment provider.

• Refunds: If Transaction is processed using aggregator A and you remove it later. You cannot mark refund and even if you can mark refund through dashboard then aggregator cannot process refund as there are no settlement to adjust.

Alternative: Transfer funds to aggregator’s nodal for manual processing

• Chargeback: If chargeback is raised then merchant needs to respond on timely basis. Merchant cannot mark refund (as explained above) and aggregator cannot recover from settlement (as explained above). Just because merchant has plugged off an aggregator that doesn’t mean merchant’s obligations are over. If aggregator loses money because of chargebacks then they can very well send court notices to merchant

Alternative: Defend chargeback with valid proof or deposit funds to aggregator’s nodal for valid chargeback cases.

Summary:

Every design and every flow contributes towards seamless user journey and better performance. The best pages and flows (Swiggy, Flipkart or Amazon) are not implemented in a week or a month but took years to reach what they are today. So you can start working on it