2

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?

Improve this question

3 Answers 3

Reset to default
1

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.

Improve this answer
1
  • cool - i think that solution sounds like the best. I don't have huge traffic, but separation will be easy to do and helps if I need to scale. Thanks
    – GWed
    Jan 8, 2014 at 16:50
0

A lot depends on wether you are building a platform, for which Implementation 1 is suitable or if it's just your own eCommerce platform, Implementation 2 may suite better.

Implementation 1 allows for scalability if you plan to offer multiple payment gateways. They all offer their own REST APIs and abstraction will provide you the scalability. If you have single gateway, advantage would be flexiblity of changing payment gatewayat a later date, which is becoming a common thing now-a-days. You will also have control in case there are network related glitches or downtimes. If you are storing data in any form, you would have to deal with PCI compliance, which is additional time and money.

Implementation 2 Will get you up and running in fastest possible manner, plus no need to deal with PCI compliance. Agreed you would have to make a second call to gateway, but it provides security on transaction validity, which would be faster compared to processing payment.

Improve this answer
1
  • thanks - I've actually just thought of another implementation. Have added to original question.
    – GWed
    Jan 8, 2014 at 13:25
0

For most cases, Implementation 1 would be more suitable. Its easier for you to secure, and probably a lot easier to debug/log.

The big problem I have with Implementation 2 is that you'd have to distribute credentials to the client in order for them to directly connect to the payment gateway. That may be possible for some systems, but I doubt all. I suspect it would also be much more difficult to debug where a problem occurs. What happens, for example, if the payment gets sent to the gateway, but you never receive the 2nd confirmation post?

Improve this answer
1
  • thanks - I've actually just thought of another implementation. Have added to original question.
    – GWed
    Jan 8, 2014 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.