Writing my own end to end payment proccessing system [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

For my final project in college I want to write my own payment processing system. It would have a backend payment processing server and client (merchant) frontend.

I would like to have the backend run and wait for connections/transactions from the client server i.e. the merchant. The backend would then do its magic and send a response to the merchant saying whether or not the payment was authorised.

I am aware of the difference between a payment processor and a bank. I want to develop the payment processor side and not the bank, nor will this system intergrate with any real banks or use real money.

In practice the payment processor talks to the issuing bank and gets authorization there. I think I could use a simple DB table of account numbers and balance for this. i.e. does the customer have enough money or not.

I want my main area of focus on this project to be on writing the backend server to be robust and handle requests concurrently. I also want to concentrate on encryption and security etc between client and server. I would like to study the PCI compliance regulations etc.

It is now early November with the deadline for the whole project in mid March 2012.

What do you guys think of my idea and do you think I could achieve something worthwhile given the time?

Answer 1

You could probably do a fairly decent job of mocking one up. In practice, most of the payment gateways wrap a lower level switch with their own communication scheme so they can integrate value-added services like fraud detection. Implementing low-level communication standards is really not required. If you want to do a decent mock-up and not spend time writing a lot of stuff from scratch, stick to the more business oriented tools with Java or .Net.

I'd suggest making a web service definition using IIS/.Net or Tomcat/JBoss/Java to define how your authorization and settlement is going to work. You can implement just about anything required by PCI DSS using tools available in the .Net/Java core libraries without having to resort to third party libraries.

Answer 2

A very similar question has come up before, and I answered here

You might have a few minor misconceptions though. Payment Service Processors (or PSPs) will generally speak to an acquiring bank. It is the acquiring bank that then (behind the scenes) redirects an authorization request to the relevant card issuer. It is done this way because the acquiring bank (same bank used by your merchant) wants to try and ensure you only settle money into (or withdraw money from, for refunds) the bank account that has been authorised.

If you wanted to have the software accredited, then you would do that with each acquiring bank you want to support, but it would involve you fully implementing the communications to the merchant bank for both authorization requests and end-of-day settlement. If this is just a mockup system then going through accreditation would be a major hurdle, and most likely infeasable with the timescale you suggested.

Instead I would focus on the challenges that PCI-DSS compliance presents. Encrypting card details is the easy bit. Writing a secure key management system is much more challenging. The overall goal would be to encrypt your card details to a database, and allow your merchants to reference those card details by unique token ids. This is the general model that PSP's adapt so that the token id can be passed to/from your merchants safely, whilst the card details themselves are kept secure, and only decrypted during communication to the merchant bank (for authorization/settlement etc)

If you wanted to keep things simple, then instead you could focus on validating the communications from the merchants that would be using your service. You could (eg) ensure that the merchant only attempts to settle an amount less (or equal to) an amount already authorised against a particular card. You could have safeguards to prevent merchants from mistakenly flooding the service with auth requests (which could rapidly drain a cardholders available funds!)

Good luck, its a great idea with plenty of scope.