I have a client who is dead-set on using PayPal for Credit Card processing. The application must be able to charge cards without the user entering the information every time. Digging around, I've found the Credit Card Vault feature, which would at least let me store credit card information for future use. Unfortunately, as far as I can tell, there's no JS based tokenization procedure in the RoR Paypal SDK gem -- in order to store data in the vault, the information first has to hit my server. Which means I have to provide PCI compliance.
Is there any way to tokenize a credit card for later use in Paypal that will let the token be valid indefinitely?
In the REST API they call it the vault and they have documentation specific to it.
In the Classic API it's called a reference transaction, in which case you would use Payments Pro (DoDirectPayment or PayFlow) to process an original authorization or sale transaction, and then pass that transaction ID into future calls to process payments with the card data PayPal has saved on their server.
If using DoDirectPayment you would use DoReferenceTransaction. If using PayFlow you would just change some of the parameters in the typical request to make it a reference transaction. The doc links above cover all of that.
As long as you aren't saving any card data on your server then the only thing you'll need to be compliant is an SSL certificate on your site, but that's becoming a recommended practice regardless of whether or not you're processing payments.
If you want to completely avoid hitting your server then you'll have to go with Payments Advanced, which embeds a PayPal hosted iframe into your site. I don't think it supports reference transactions, though, and it's a lot more limited than REST or Payments Pro.
Related
I am working on an e-commerce site which allows user to purchase a product in 3 monthly instalments. Previously I was using Stripe payment gateway for instalments. I was using Stripe webhooks to update my system after instalments gets paid.
Now I have to achieve the same thing using Moneris(Canada) payment gateway. There are official libraries for Java, PHP & .NET but I am using Ruby. I looked into ActiveMerchant. It allows single charge but I couldn't find anything about recurring payment support.
As far as I know there is no any webhook support but I am looking for API's which I can schedule to run to fetch data from Moneris & update my system accordingly.
I would prefer using ActiveMerchant & a bit of custom code to update my system. I am looking for a good starting point which can lead to a better solution given this scenario.
AFAIK Moneris at this time doesn't support access to reporting via API so there's no programmatic way of checking that a recurring payment was successful or not, neither through webooks or through reportings.
This answer suggests another solution...
Looking for some one who has implemented Moneris recurring payments for a website subcription
...which is basically just storing the credit cards on Moneris in exchange for a token, presumably, (what the poster refers to as "the vault") and then setting up your own scheduler to request payments as needed and getting real-time feedback on success or failure of payments.
I'm a Freelance developer creating a site for a start-up company.
Getting PCI compliant at this time is going to be tough, since the site is still in major development and the funds are quite short.
The situation is this: They want to accept payments on demand in a fast and easy way. This is going to involve punching an id followed by a PIN into a virtual pinpad. This should process the transaction, charge the card, and be done. Because we are not currently PCI compliant, I would like the security to be as follows:
User, in Account Management, can click a link to redirect to the third-party payment processor (We are currently using Authorize.Net). On this page, the user enters their card information followed by email/some form of ID. Their card is saved through this third-party, and the third-party sends us their ID for the user as long as the user email (Or whichever identification used on our end). Now, when the user wants to create a transaction, we send the User ID, our API Key, and the transaction Key used by the third-party as well as the amount to charge. They charge the account and all is good.
Anybody have experience in this? Is this possible? Other solutions are welcome. Again, the company is slightly low on funds, and the transactions are usually going to be ~$10. They are currently working through 100% cash right now and averaging about 30 transactions a day, which is expected to increase drastically over the summer.
Unfortunately, with the new DSS 3.1, you may still need to perform a SAQ A-EP. Part of the requirements for the SAQ A-EP are:
Your e-commerce website does not receive cardholder data but controls how consumers, or their
cardholder data, are redirected to a PCI DSS validated third-party payment processor
Even though your site never takes or processes credit card data, since your site does perform a redirect, that redirect could be changed to point to a malicious site.
Further information can be found in the SAQ A-EP.
Can't understand which PayPal API to use.
I have Rails app and I'd like to accept credit card recurring payments via PayPal. At first I was thinking to use Express Checkout API that supports recurring billing and can work even if a user doesn't have PayPal account. But then I saw that their official ruby gem merchant-sdk-ruby https://github.com/paypal/merchant-sdk-ruby will be deprecated:
This Classic SDK is not actively supported and will be deprecated in
the future. For full support on new integrations, please use the Ruby
Rest SDK
So I don't want to use something that will be deprecated soon. But I can't understand whether I can use REST API to accept credit cards without being PCI-compliant.
I'd like to redirect user to PayPal where he could enter his credit card info and return back to my site like in Express Checkout, but I see only examples where credit card info is collected on my site and passed to PayPal via API that implies more security headache on my site.
UPD: I found some information regarding this question in Accept a PayPal payment section of REST API documentation that is a bit odd because I expected to find it in Accept credit card payments section. They say:
Important: To receive Guest Checkout payments, which allow credit cards, ensure that PayPal Account Optional is enabled on your account
settings. For example, here is the path for US accounts:
Profile > My selling tools > Website preferences > PayPal Account Optional
But I'm still not sure whether it will work in my case. Now I have the following question:
Can I use Guest Checkout feature to accept recurring payments?
Can I test Guest Checkout in Sandbox? And if I can what credit card number to use?
Can I show by default form for entering credit card info when user gets to the PayPal site rather than for entering PayPal credentials?
Ughh... why it is so complicated?
There are couple of samples in PHP code, that could help you understand recurring payment options in REST API.
https://github.com/paypal/PayPal-PHP-SDK/tree/master/sample/billing
Or you could follow up the docs on : https://developer.paypal.com/webapps/developer/docs/api/#billing-plans-and-agreements
I will look into this specifically and get back to you
For trying it out on sandbox, you can create an account here at https://developer.paypal.com/webapps/developer/applications/myapps You need to create an app, and it would generate a valid credit card for you.
This may be very unlikely to do, but I can ask the internal team if they know of any such option.
Railscast #289 is on this. It requires that you sign up for the pro version. Looks pretty involved but he walks you through it.
I'm currently working on an iOS app where I would like to control the user experience of the entire checkout process when the user is paying directly by credit card. The PayPal iOS SDK doesn't quite fit my use case as it has a baked in ViewController that must be displayed to complete the payment.
The PayPal REST API's appear to allow me to charge a user's card directly but would require my secret key in the process implying it should only be used for some server side flow.
The PayPalPaymentViewController does have an option to take credit card payments directly from the user so I wonder if these services being used to accomplish this are publicly available?
First, I'd be curious as to why the provided view controller is inadequate. The goal is to provide a minimal interface in which to accept credit cards.
But, yes, these services are publicly available. A limited set of functionality (e.g. sale transaction) is possible by omitting the OAuth2 secret.
However, you will still want to verify the transaction on your own server in order to avoid being spoofed by a malicious user.
Don't try to replace the paypal ViewController with anything else, you might run into lots of legal trouble. For example, here in germany, the size and text of the "purchase" button is regulated by law. Paypal's Lawyers have checked the german version of the ViewController for correctness. If anyone, in germany, uses your app, and makes purchases with a different UI, chances are very high that a) the transaction is void and b) german authorities will prosecute you for fraud. Don't risk that.
I was wondering how can I send customer credit card data from ecommerce website to Quickbooks. There are some concepts i am confused.
From my understanding, basically I can process credit card on my ecommerce website using "Merchant Service for Web Stores" API, and i found there is a "Payment wallet" function, is the connected to customer credit card info on desktop Quickbooks? What's the proper way to process credit card for my ecommerce site and at the meantime sending the customer credit card data into my desktop Quickbooks, saved there and for future use?
Any help would be greatly appreciated.
ps: The ecommerce site is by PHP
I was wondering how can I send customer credit card data from ecommerce website to Quickbooks.
Are you sure you actually need the credit card data in QuickBooks? You should know that if doing this, you likely won't be PCI compliant without jumping through a lot of hoops - and remember that storing credit card data on site is incredibly dangerous from a litigation/security/legal standpoint. You're setting yourself up to get sued when that data gets stolen.
From my understanding, basically I can process credit card on my ecommerce website using "Merchant Service for Web Stores" API,
Yes.
and i found there is a "Payment wallet" function,
Yes, and this is what you should be using. It securely stores the data with Intuit instead of with you, so that you are still PCI compliant and the card data is safe.
It allows you to push credit card data to Intuit, and they return a unique ID value to you which you can use to charge the credit card at any time in the future, without actually having to know the card number itself.
is the connected to customer credit card info on desktop Quickbooks?
No, it's not.
What's the proper way to process credit card for my ecommerce site and at the meantime sending the customer credit card data into my desktop Quickbooks, saved there and for future use?
You don't want to do this. There is no proper way to do this. It's a terrible, insecure practice. Don't do it.
Instead, charge the credit card via the QBMS API, and then store the credit card in the payment wallet and store the payment wallet unique ID in your database. You can then write a simple program that lives and uses that unique wallet ID to charge them again at any time.
Since you're using PHP, this is the best place to start (disclaimer: I'm the author of the below code):
open source QuickBooks PHP DevKit
Specifically, you'll want to look at the QuickBooks Merchant Service examples:
PHP - charge credit cards with Intuit QuickBooks Merchant Services
PHP - store credit card info securely with Intuit QuickBooks Merchant Services
Before you can really utilize the code, you'll have to go through a very simple registration process with Intuit (register in DESKTOP mode for easiest implementation).
Quick-start for Intuit QuickBooks Merchant Services with PHP