CODEWITHSUNDEEP
apirestpaypaltransactionspayment-gateway
Techie
Techie

Reputation: 45124

REST API Transaction For Payment Platform

Following is an architecture that is designed to develop a payment platform for an organization(shown as 3rd party). Each and every entity has set of REST APIs. For the time being let's say I'm developing something like Paypal.

enter image description here

I have clearly marked the boundaries by vertical lines(red,blue). There are three parties involved. Payment portal, bank and 3rd party.

  1. Customer can initiate a transaction by log in to the payment portal. Payment portal will invoke the bank's API. Request flow is shown in the picture.
  2. Each and every request and response will go through the ESB and will be logged. If the transaction is successful ESB will update the 3rd party database and inform the payment portal at the same time.
  3. Payment portal will initiate another API call to the ESB to make sure that 3rd party database is updated correctly(not shown in the picture).
  4. At last payment portal will send an acknowledgement to the banks that the transaction has gone the full cycle(not shown in the picture). This is another API call.

The problem is what if the there is a network issue between two parties and it's unable to complete the truncation cycle. How it should be addressed?

Let's assume that network between payment portal and 3rd party is lost once the payment portal initiated the request. Payment portal will not be able to get the response even if the transaction is successful at the bank's end. Once the network is bank online how this should be handled?

I have read below.

Transactions in REST?

Upvotes: 0

Views: 1500

Answers (1)

Opal
Opal

Reputation: 84756

First of all you should forget about processing the transaction synchronously.

In the first scenario you initialize a transaction and transaction data - with it's status - with 200 OK code is returned. At the beginning status may be e.g. Started. Then you repeatedly send a GET request to fetch all the transaction data and display appropriate info when its status is changed to e.g. Finished. In this scenario if the connection between client and server is broken nothing bad happens - all the data are kept on the server side and the client behaves as an observer. Summing up, 200 OK code is used along with status of transaction.

In the second scenario the HTTP status code indicates if transaction is finished or not. If transaction is started/submitted the response contains transaction data and it's marked as 202 Accepted. There's no internal status field. You should then repeatedly query the endpoint till 200 OK or 204 No Content is returned (in case of a correct answer) or 4XX (5XX) in case of any failure.

These two approaches are different only when it comes to indicating the fact that transaction is finished or not: via an resource internal field or HTTP status code.

Upvotes: 1

Related Questions