In this post we will walk through the integration points in the path of transaction processing, with a couple of examples from the market, Chase and Marqeta. In the next post, we will go through the integration points related to clearing and settlement of the transaction.
Let’s add below again the card payment diagram but with highlighting the integration points in alphabets, and where ledgers are maintained for the different balances.
Terminal - Facilitator Integration:
These are points A and B in the diagram. These points were used to be ISO8583, and on GSM and GPRS. Now modern terminals can connect using internet connection on Wifi in the store or the restaurant. Even many of these calls are now using REST over HTTPS.
Many facilitators now make you initiate the payment, not directly through the direct connection between the PoS and the terminal on WiFi, but goes first through the cloud systems of the facilitator and then forwarded to the payment terminal, to be shown to the card holder for payment. Payment terminals and their integration with PoS applications is another long topic to be addressed later.
For online payments, all facilitators provide different methods to embed the payment widget in the checkout page, and redirect to the facilitator payment page, Stripe Checkout APIs and widgets as an example.
Facilitator - Acquirer Processor Integration, Chase as an Example:
This is point C in the diagram. These are usually REST APIs provided and published by the acquirer processor.
For example, Chase (or ChasePaymentech) as an acquirer processor offers APIs to onboard merchants by the facilitator. It is called a merchant for the facilitator but a submerchant for the acquirer processor.
The WePay "Core" APIs are created by Chase for third party and partners integration. The APIs allow the facilitator to register submerchants, and during the registration, the MasterCard MATCH APIs are called to check on the high risk merchants as a due-diligence that needs to be done by the facilitator before onboarding new ones.
The other "Clear" module in WePay APIs is more around processing the transaction:
- First as a payment facilitator, your checkout page, which your merchant redirects to, shall read credit card data from the end user. This API from Chase uses iframe to collect card data from the end customer or purchaser. The credit card information is submitted directly into Chase backend systems, without passing through neither the merchant site, nor the facilitator systems, which makes the PCI-DSS compliance requirements on the facilitator a bit simpler.
- After creating and tokenising the credit card, the facilitator shall call the Process Payment API to send the transaction.
- If the transaction is authorised and needs to be captured, another API shall be called to capture the payment. For example, some e-commerce sites authorise the payment amount and hold it, then capture it later when the goods are shipped.
Acquirer Processor - Card Network - Issuer Processor Integration:
Points C and D. These are managed by the Network Card Interface hardware and software provided by the card network and hosted inside the acquirer and issuer processors premises.
Issuer Processor - Issuer Bank Integration:
Points F and G. We will take Marqeta as an issuer processor example. It has already a connection into the card network in point E.
Marqeta maintains the balances of the cards in what is called GPAs or General Purpose Accounts. For credit, charge, and prepaid cards, the transaction is approved and response is sent back by Marqeta directly without getting back to the issuing bank.
For debit cards, the issuing bank has to be called by Marqeta to check the balance of the account and thus accepts or declines the transaction.
This interface has to be implemented by the issuing bank as what Marqeta calls JIT (Just In Time) Funding Gateway. This gateway shall be invoked by Marqeta to:
- Check on the account balance for the debit card, where its account balance is maintained at the issuer bank.
- Once transaction is approved and completed, Marqeta notifies the issuing bank with the transaction so it updates its accounts balances and ledger in its core banking.
Only once as part of the integration setup, the issuer bank shall call /fundingsources/programgateway in Marqeta APIs to register its endpoints that will be called later by Marqeta for transactions processing.
Then for each transaction:
- Marqeta will call this endpoint with jit_funding object in the body, as described here. This JSON body in the POST call includes all the information the bank needs in order to approve or decline the transaction based on the card holder bank account balance.
- The call is synchronous, and the issuer bank shall respond with 200 as approval, with jit_response object in the response, as explained here.
- Once the transaction is completed by Marqeta, Marqeta notifies the issuer bank with the transaction completion with the JIT notifications. This is another endpoint that is registered as a webhook in Marqeta, so Marqeta can call it for notification on subscribed events. Transaction events are the ones related to synchronisation of the ledger.
It is good to note the transaction is authorised, captured and cleared at Marqeta. The issuer bank is only called to check the balance and to update the accounts ledger. From a bird eye view, you can see that the acquirer bank is not involved at all in the transaction. The acquirer is only involved in the reconciliation, settlement, and paying out to merchants.
Discussion on Gateway Design
Let’s brainstorm, if we are the issuing bank, how we can design the funding gateway. We can think about the following architecture:
- The two endpoints (to check balance and for notifications) can be exposed using API gateway. Since these endpoints are in the core of the bank business, they shall be hosted on an API gateway installation or tenant other than the ones for B2B or B2C purposes, for open banking for example.
- There shall be some integration service to read the API request with jit_funding object data, and connect to the core banking system to check the balance.
- This service shall be scalable and stateless. You can see that the call starting from Marqeta to the issuer bank doesn’t include any card holder data, in other words, card payment sensitive data like PAN, Expiry Date, PIN, or CVV. This means that this leg in the transaction path is not covered by PCI-DSS audit. This gives you a lot of freedom in choosing the runtime of this service. Managed serverless runtime like Lambda in AWS or Azure Functions are good options.
- In order to avoid the data race problem, once Marqeta calls this service to check the balance, if the balance is enough to approve the transaction, the service shall call the core banking system to hold the amount.
- For the notification endpoint, this one can be processed by the issuing bank in an asynchronous manner. Which means, a FIFO queue can be used as the integration medium between the API gateway and the integration service. Once the notification is received, the held amount is captured in the core banking system.
To the next post.