I was looking into the Paypal Vault capability and found the following suggested sample code:
https://github.com/paypal/PayPal-Java-SDK/blob/master/rest-api-sample/src/main/java/com/paypal/api/payments/servlet/CreateCreditCardServlet.java
And this example contains this:
CreditCard creditCard = new CreditCard();
creditCard.setExpireMonth(11);
creditCard.setExpireYear(2018);
creditCard.setNumber("4417119669820331");
creditCard.setType("visa");
The servlet creates a credit card object and submits it to Paypal Vault. The example seems simple. However, the fact that my server has to process credit card and send them to Paypal worries me. Doesn't this suggest PCI compliance and so defeats the purpose of the Vault?
If you use the REST APIs for direct card processing, you need to validate your own site against PCI-DSS. Since VAULT deals with direct card payments, you will need to be PCI compliant if you are using VAULT.
https://developer.paypal.com/docs/faq/
I think the Vault API should be changed 'cause it seems there is the possibility to store also the CVV2 even if that field cannot be stored anywhere due to PCI Compliance (and the fact that you do not store that value is confirmed in a Github issue).
Changing the API will be great, I think.
Cheers
Related
The Paypal REST API has an endpoint that allows saving a customer credit card information into the vault.
The problem is that I don't want to manually deal with credit card information on my frontend (and I believe it wouldn't be PCI compliant?) and then call that endpoint to store it in the vault.
Is there any other way to store a credit card in the vault? Maybe using hosted fields/pages? I've been searching the documentation but I haven't found any way to do this.
I am looking to add PayPal Vault support for an application but can't find in the PayPal documentation as to whether it support Purchasing/Procurement P-Cards.
I would just setup a test inside the sandbox and see whether it worked but I am not aware of any test p-card numbers that can be used for this purpose. Does anyone have any experience using p-cards with the vault API? I'm using test credit cards from
https://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/credit_card_numbers.htm
but can't find a way to distinguish between normal credit card numbers and p-cards numbers.
Thank you.
Depends on the P-card. There are a couple of considerations to bear in mind:
Does the card have a BIN that corresponds to a card type that PayPal supports (e.g., Visa, MasterCard, American Express, or Discover)? If not, then the answer is no.
Does the issuer require Level 2 or Level 3 data to be provided with each transaction? If so, then the answer is no, as PayPal doesn't support L2 or L3 data on card transactions. (In my experience, a lot of the P-cards being used by US Government employees require L3 data to be provided.)
Otherwise, you should be OK.
I'm using Paypal Pro API to process my purchase. It works well with card number, expire date and security code but I need to validate the address and the owner name of the card as well.
Is there any parameters or functions in the API to do this? I didn't found anything in the docs. Or maybe it is an additional option in the Paypal developer control panel?
Assuming that we're talking about the Payflow Gateway API (for PayPal Payments Pro and other things), it appears you can do address verification--see the section entitled Using Address Verification Service. Notice the note there that says it doesn't check street names, in case that's a deal-breaker for you.
As for name validation, I can't find anything about that other than that it's typically passed in the sale transaction itself (section: Typical Sale Transaction Parameter String). Whether it's then validated by the banks as part of their end of the transaction, I couldn't say.
Hope that gets you a bit further. I haven't worked with any of this stuff myself.
Has anyone yet dabbled with Paypal's REST API call for Direct credit card payments ?
This resource resides here:
https://api.sandbox.paypal.com/v1/payments/payment
The typical way to process this account is:
Get access token by making an API call that includes the Client_ID and Secret.
Using the access token, I make a call to the payment API with the necessary card specific data.
In point number 2, the line 'necessary card specific data' is important. So far, I had been testing using one of my test/sandbox business accounts. That is, the credit card data that was specifically generated for this account. However, it seems like I can manipulate the name, change the expiry date (as long as it's a valid date), the CVV2 number. As long as the credit card passes a MOD 10 check, the response object shows the payment as processed (state: approved) .
My question is, is this a loophole (unlikely) or just by design that paypal allows any random card related data to verify payments. (as long as they are valid credit card numbers).
If it is the earlier, then I wonder why Paypal wants me to create a business account and generates credit card data for me, when all I really need is the REST API client id and secret that is provided when I sign up as a developer.
Disclaimer: The documentation does not state anywhere that random card related data can be used.
Correct, this is by design. We'll accept any credit card number in the Sandbox environment as long as it adheres to MOD-10. This is done specifically to allow for easier testing in the Sandbox environment.
If it is the earlier, then I wonder why Paypal wants me to create a
business account and generates credit card data for me, when all I
really need is the REST API client id and secret that is provided when
I sign up as a developer.
I'm not quite sure what you mean here though?
Suppose some online retailer uses XYZ Bank's payment gateway. Is it possible to do the job of filling in card details and proceeding through the entire process using a script? If yes, is it legal?
Update:
To make the question more clear, I'll give a scenario.
Suppose the retailer we're talking about is Amazon, and I wan to use a card/netbanking (not PayPal). I want to be able to place an order on Amazon using a script which does the job of filling my cart and making the payment. Say the cart thing has been taken care of. How do I automate the payment process now? If it's allowed that is. Card details etc will not of some user, but my own, so no security issues with that I suppose.
The payment API would usually support something like this. For example, if we look at Paypal's direct payment api, they provide secure means for you to pass credit card numbers, etc to Paypal to process the payment.
If you are thinking to do this to process recurring payments, then you are doing it the wrong way. You should never store any credit card details unless you are PCI-DSS compliant. This takes a lot of work and auditing, so it is somewhat rare for small and medium companies to do it. For recurring payments, store the credit card numbers with your payment gateway (most should provide a means to do this) and the gateway should return a token to store. Every time you want to charge the card, simply pass the token to your gateway.
Given the new information:
What you are trying to do is to automate the browser (that's the best way to do it). You could write a script that connects to Amazon, loads the page, fills in the POST variable, send it back, get results and so on, but it is not very robust. For example, if amazon changes the name of a few post variables or even the markup, then your script would fail.
The best way to do this is to use a Browser Automation framework. Selenium is prbably the most popular and most well known. It is often used to automate testing user interfaces, but it is also useful for doing something like you are suggesting. You can use Selenium IDE which is a Firefox addon to quickly reproduce and replay recorded actions. For something more advanced and highly scriptable, try Selenium WebDriver.
As for whether this is legal or not, I don't see why it shouldn't be legal if you are using your own credit cards and what not.
If you are using your own credit card details it's at your own risk so very minimal legel issues. But it's always a good idea to store & transmit(SSL) card details encrypted for some peace of mind. But if it's for wider public you will need to look into PCI guidelines and matching class requirements.