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:
Allow users to securely store and process their payments
How does Paypal handle the transactions?
Handle payments through existing banks. I am guessing that I would need access to local bank protocols to get this.
Where I can find documentation of paypal or any other payment gateway to get the idea of its core functionality
Thoughts?
If you want to directly integrate with banks, you want to become a payment processor. This is quite hard to achieve (especially on the compliance side) and the market is dominated by a few giants (First Data Corp., Total System Services Inc. (TSYS), Vantiv Inc., Global Payments Inc. and Heartland Payment Systems Inc.).
A payment gateway however is a system that accepts card payments, and offers value added services such as recurring payments. Gateways (unless they are a processor themselves) most often delegate the actual processing of the cards to a payment processor.
Becoming a gateway is easier and you can even partner with ISOs which will provide you with white-labeled solutions (e.g. Intrix). You can also take a look at Kill Bill for an example of an open-source payment gateway.
Regarding security, if you want to minimize PCI compliance, you can delegate the actual storage of the card to online vaults.
Related
I'm developing a flutter app, and I've come across different payment solutions such as
squareup payments, paystack and stripe. However all these systems essentially require you to setup an account with their services, then you can only charge money to those accounts.
What I'm looking to do is enable monetary transfers between users on the app, and simply charge a fee on top. What are the best practises for such a system? So a callable api in the vein of Venmo, or Square Cash that I can call from code when I get the details I need.
Should I create my own backend for this? If so what should I use? (I'm primarily working in golang, but I'm flexible)
Or is there a nifty flutter plugin or API gateway that I can just use directly from the mobile client?
There are various services for doing such a thing,
Usually at my firm we would have our .NET rest server get the payment request from the client, and later charging it with some service that is verified for payments at our country.
Note:
You will be needing to associate with that service and there will probably be fees.
Depanding on your country, you most probably MUST NOT store the payment data on your own server unless you have a certificate for doing such a thing (security standerts etc.)
If this is a private project I would suggest researching about migrating with PayPal since you won't need to handle security and the payment would go through them.
May be helpful: paypal developers
I am looking for a payment processor that supports N-Payer->1-Payee.
As documented https://developer.paypal.com/docs/api/payments/#payment_create,
users make payment requests by providing the server with a payment object. Within the object, there is a payer field which specifies the source of the funds for the payment.
(Disclaimer: I work for Stripe.)
Stripe does not support this directly -- you'd have to create as many charges as there are payers.
Due to the way card payments work, I'd guess that all card processors have the same limitation, though maybe other processors have built features to better handle such payment flows.
as the questions implies, I am in the process of deciding on a payment gateway solution for an online financial service. The gateway should allow customers to pay using prepaid cards without providing a phone number, address, legal name, etc. Ideally the gateway will also allow instantaneous access to cleared payments, but this feature is less important. Will PayPal meet either of these requirements when using the REST API and the direct payment system? I was unable to find a concrete answer in the documentation. If not, are there any competing payment processors which offer support for charging prepaid cards without identify verification? Thanks in advance.
As of now, no U.S based payment processors allow processing prepaid cards without some form of identifying information about the customer, and PayPal is no exception. However, a representative from PayPal mentioned that a feature allowing anonymous payment has been requested by many merchants and is in development.
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
We currently use the Website Payments Pro recurring billing solution from Paypal for a SaaS web application (user signs up for a monthly billing subscription to our service) but are becoming increasingly concerned that all of our credit card data is 'locked in' to Paypal and we can never get access to it.
The ideal for us is at the point of signup to store a users credit card details in a third party system (vault) whilst processing the transaction through Paypal's Website Payments Pro billing solution. This would give us the freedom to change our payment processor without having to ask everyone of our users to re-enter their card details - storing payment details in a third party PCI compliant system would allow us to do this.
Does anyone know of any such solutions that would allow us to store credit card details without transacting against them and whether these would be available to UK based companies ?
Thanks - appreciate any help you can give.
Mike
PayPal now offers such a service
https://developer.paypal.com/webapps/developer/docs/api/#vault
I found that Briantree.com offers that service
I'm not aware of anything that does this (but would love to hear otherwise). The reason it doesn't exist I would assume is because 'my' PCI-DSS requires that any third party that I pass card details to is also PCI compliant.
Therefore, this 'vault' provider would only be able to return to you a full card number if you were fully PCI compliant (and if you were, then why would you need to use a 3rd party vault?!)
So the best you could optimistically hope for is a 3rd party that both vaults the details and also allows interaction with 'n' other payment gateways, but this would obviously only allow you to switch between gateways that the vault supports. Given that the 'vault' would need to generate income, as well as the gateways that it communicates with, I can't see this being cheaper than choosing and interacting with a single gateway directly.