I have a RESTful API that offers eCommerce functionality. One area I'm struggling to decide on the correct implementation is how to process payments.
Lets say I have the following URI GET …/checkout/{id}/payment. This resource provides details to the client application of what details needs to be submitted to make a payment. The specifics of the information in the resource depends on the implementations below
Implementation 1 The resource contains basic payment fields to be filled in like card number, billing address etc. The data is sent to the API using POST …/checkout/{id}/payment. The API then submits a request to the payment gateway (e.g. paypal), waits for the response, and then sends an appropriate response back to the client application.
Implementation 2 The resource contains details of how to submit a request directly to the payment gateway (e.g. paypal). The client submits the payment to the gateway, waits for a response, and then sends the payment reference (normally always provided by a payment gateway) back to the API using POST …/checkout/{id}/payment.
The problem I am having is that both have pros and cons.
Implementation 1 I would say is the more fail safe method as everything is contained in one request to the API. The API can then update backend tables once the payment has been processed, and return success or failure status to the client. Since the API is sending a response to the gateway, it knows the response it receives is genuine.
Implementation 2 frees the API from having to process the payment which is great, but requires the client to make two requests. One to the payment gateway and one to the API with the reference. Additionally, how can I validate the payment reference on the API without calling the gateway? A dishonest client could send any reference back to the API which then may be incorrectly marked as paid.
Just wanted to throw my ideas out there, but if anyone has a really good solution for implementing Payment Gateways and RESTful API web services that would be great.
UPDATE
Just thought of an Implementation 3. I could actually create a separate smaller API to handle the payments. It would work in a similar way to implementation 1 except that the client application doesn't post to api.site.com/…. but posts to gateway.site.com/… This give me a degree of security as I control the code on gateway.site.com and ensures that api.site.com isn't being bogged down by waiting for the payment provider to respond. The gateway api then essentially becomes a client of the main API and posts the payment success details to it.
Any thoughts on this?
Best Answer
I assume you are expecting your site have a large amount of traffic. If that assumption is correct, I would say go with a tweaked version of Implementation 3. If api.site.com and gateway.site.com are on two different servers, I would also have a third server to house the DB and have both apps leverage the centralized DB. This will eliminate the need for api.site.com and gateway.site.com to even know about each other and keep all work in a designated area, making any debugging that much easier.
And if my assumption is incorrect, I'd say go a differently tweaked version of Implementation 3. So you'd build you two separate apps that communicate with the same Db, and simply house everything on the same server. Which is basically what I just said above but all on the same server. This should reduce initial overhead and make scaling a breeze when the time comes.