169

So this question isn't about integrating an existing payment gateway into my site. This is more of a architectural question.

I want to build a system similar to Paypal. Now I understand that Paypal offers a lot of features under the roof and I can't implement all of them at once. I want to implement the core functionality of Paypal and other such services.

So my question is (rather discussion is) around how would one go about building such a system. Some points to discuss:

  1. Handle payments through existing banks. I am guessing that I would need access to local bank protocols to get this.
  2. Allow users to securely store and process their payments
  3. How does Paypal handle the transactions?

Thoughts?

Obaid
  • 4,328
  • 9
  • 42
  • 42
  • 3
    this question was up voted a lot. im wondering are white papers etc harder to come across these days because these platforms don't want this information being readily available. – filthy_wizard Sep 01 '19 at 07:49
  • ^ very true. I have seen many great questions unfortunately discouraged – Ralph Dingus May 17 '20 at 22:25

2 Answers2

230

What you're talking about is becoming a payment service provider. I have been there and done that. It was a lot easier about 10 years ago than it is now, but if you have a phenomenal amount of time, money and patience available, it is still possible.

You will need to contact an acquiring bank. You didnt say what region of the world you are in, but by this I dont mean a local bank branch. Each major bank will generally have a separate card acquiring arm. So here in the UK we have (eg) Natwest bank, which uses Streamline (or Worldpay) as its acquiring arm. In total even though we have scores of major banks, they all end up using one of five or so card acquirers.

Happily, all UK card acquirers use a standard protocol for communication of authorisation requests, and end of day settlement. You will find minor quirks where some acquiring banks support some features and have slightly different syntax, but the differences are fairly minor. The UK standards are published by the Association for Payment Clearing Services (APACS) (which is now known as the UKPA). The standards are still commonly referred to as APACS 30 (authorization) and APACS 29 (settlement), but are now formally known as APACS 70 (books 1 through 7).

Although the APACS standard is widely supported across the UK (Amex and Discover accept messages in this format too) it is not used in other countries - each country has it's own - for example: Carte Bancaire in France, CartaSi in Italy, Sistema 4B in Spain, Dankort in Denmark etc. An effort is under way to unify the protocols across Europe - see EPAS.org

Communicating with the acquiring bank can be done a number of ways. Again though, it will depend on your region. In the UK (and most of Europe) we have one communications gateway that provides connectivity to all the major acquirers, they are called TNS and there are dozens of ways of communicating through them to the acquiring bank, from dialup 9600 baud modems, ISDN, HTTPS, VPN or dedicated line. Ultimately the authorisation request will be converted to X25 protocol, which is the protocol used by these acquiring banks when communicating with each other.

In summary then: it all depends on your region.

  • Contact a major bank and try to get through to their card acquiring arm.
  • Explain that you're setting up as a payment service provider, and request details on comms format for authorization requests and end of day settlement files
  • Set up a test merchant account and develop auth/settlement software and go through the accreditation process. Most acquirers help you through this process for free, but when you want to register as an accredited PSP some will request a fee.
  • you will need to comply with some regulations too, for example you may need to register as a payment institution

Once you are registered and accredited you'll then be able to accept customers and set up merchant accounts on behalf of the bank/s you're accredited against (bearing in mind that each acquirer will generally support multiple banks). Rinse and repeat with other acquirers as you see necessary.

Beyond that you have lots of other issues, mainly dealing with PCI-DSS. Thats a whole other topic and there are already some q&a's on this site regarding that. Like I say, its a phenomenal undertaking - most likely a multi-year project even for a reasonably sized team, but its certainly possible.

PaulG
  • 13,871
  • 9
  • 56
  • 78
  • 1
    Thanks Paul that is great information. That's exactly what I was looking for. One of our customers is looking for a solution to implement in South Asia. We weren't 100% sure hence the questions on SO. – Obaid Apr 16 '10 at 19:01
  • 1
    Thank @PaulG , I also appreciate your answer. Please let me know one thing. What is card acquiring arm? Is this the same with the organisation who provide the Merchant bank's processor.Could you please give me any references about that ? – Frank Myat Thu Dec 16 '11 at 04:08
  • Hi Paul and @Obaid I'm trying to build my own payment gateway. However I'm building it around cryptocurrency and I'm not dealing with banks. The infrastructure to transfer funds is done but I want to know how to deal with security issues and which points to consider when doing it. Have you done this? Could you help me which cases I should look into? There are not many resources online to do this. Thanks in advance – Alireza Noori Jun 05 '17 at 13:06
  • I worked at a company that dealt with this so i have a good idea how this could be done. However, they never paid their contract invoice so i have all this source code sitting on an external drive lol. Might try to sell what I had written. That said, essentially these days there's alot of API's you can use to tie everything together and create a payment processor website. I'd start by looking at what exists with API calls that you could use with your site. Once alot of money comes in, then you can use that to start replacing those outside api calls with internal code. – Multiplexor Dec 21 '17 at 20:14
  • @AlirezaNoori a good start is to just become PCI compliant with regard to transactions and database policies. Even though it's not required for bitcoin, it works as an effective guideline for security – That Realty Programmer Guy Jan 09 '18 at 13:09
  • @GaretClaborn hi, where do i find the card network API's to integrate with my backend? Can these be found online or do i need to contact an acquiring bank first and they will provide me with the necessary API's? – kd12345 Mar 04 '21 at 09:07
  • 1
    @kd12345 that depends somewhat on your goals. There are certainly card APIs like Square and Stripe which allow you to take card payments. There are libraries like Payum, or better the Payum Server, which let you control 50+ payment gateway APIs with one, simpler API. Many banks do offer APIs such as Chase and Wells Fargo with public developer docs, for other transactions. https://cryptoapis.io/ is an example API that connects many APIs for trading cryptocurrencies. Of course, if you do have bank connections you may gain access to more specialized private financial APIs – That Realty Programmer Guy Mar 07 '21 at 01:26
  • @Multiplexor, how can I reach you? – Ibrahim Hammed Jul 16 '22 at 17:30
-11

Big task, chances are you shouldn't reinvent the wheel rather using an existing wheel (such as paypal).

However, if you insist on continuing. Start small, you can use a credit card processing facility (Moneris, Authorize.NET) to process credit cards. Most providers have an API you can use. Be wary that you may need to use different providers depending on the card type (Discover, Visa, Amex, Mastercard) and Country (USA, Canada, UK). So build it so that you can communicate with multiple credit card processing APIs.

Security is essential if you are storing credit cards and payment details. Ensure that you are encrypting things properly.

Again, don't reinvent the wheel. You are better off using an existing provider and focussing your development attention on solving an problem that can't easily be purchase.

vfilby
  • 9,938
  • 9
  • 49
  • 62