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.
Related
Our use case is:
The seller sells the product to our platform, the buyer buys with PayPal and payment needs to get split to seller and owner of platform using PayPal
Any idea how to achieve this? We have found ways but they are depreciated in PayPal. Any alternative to achieve using Paypal.
Please help us to find it.
Thanks a lot
Two alternatives to implementing this feature are: Stripe Connect and Braintree Marketplace. These products enable you to choose how you manage the risk give most of the supporting features for a platform payments.
These are paid services, and the cost may prohibit your app. Another alternative is implementing this logic yourself, where you will have to keep track of the sales, the percentages to take for each one for taxes, commissions, fees, and the ledger to ensure money is not lost.
Some open source solutions can help you with the in-house implementation, such as QLedger. Other managed solutions offer pieces of this infrastructure as a service, such as Decimals [disclaimer: I'm the founder of Decimals]
You need to make sure you are aware of the risks of your platform. You won't be able to get money already sent to the seller Paypal account on chargebacks/refund requests, and will have to pay for them yourself.
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.
I would like to support payments in my web application which acts as proxy between group of customers and merchant. I'm still trying to research this, but I'm new to subject and a little confused. Maybe someone could point me to good direction.
Is below scenario possible with paypal services (or other similiar sites)?
Customer creates account and my application stores his billing data
(credit card number) in 3rd party service, so I don't need PCI
compliance certificate
Customer A, B and C are creating common
group order from one of registered merchants. For example there are
3 products in this global order.
After some time one of customers
accepts group order and application create 3 payments to merchant
without needing confirmation from all customers
Those orders will be daily and payment will be delayed so that's why I don't want confirmation from users.
I was reading on Paypal site about Adaptive Payments, but there is step "Redirect the Customer to PayPal for Authorization", so I assume it's not for me, because it needs confirmation.
https://developer.paypal.com/docs/classic/adaptive-payments/ht_ap-basicChainedPayment-curl-etc/
I'm from Poland so Paypal Direct Credit Card Payments are not available for me.
https://developer.paypal.com/webapps/developer/docs/integration/direct/rest_api_payment_country_currency_support/#direct-credit-card-payments
I found REST operation - store a credit card so maybe one thing is easy :)
https://developer.paypal.com/docs/api/#store-a-credit-card
Let me see if I can answer your questions (I'm with PayPal / Braintree), and I'm perfectly fine with you asking it here.
The short answer to your question is that yes, this is absolutely possible with PayPal services. Let's break down each part with some options:
Storing billing data
It looks like you already found the answer here - you can absolutely use the vault for storing that information (https://developer.paypal.com/webapps/developer/docs/integration/direct/rest-vault-overview/).
Creating an order for later capturing & Capturing the payment
What I would look into here (to see if that works for your needs) is the auth-capture mechanism (auth: https://developer.paypal.com/webapps/developer/docs/api/#authorizations and capture: https://developer.paypal.com/webapps/developer/docs/api/#captures). Here's how it basically works:
- You use authorize to hold funds in the buyer's account for a period of time.
- From the auth you will get a key back that will allow you to reference that authorization in the capture step
- When you are ready to capture, you simply use the capture endpoint with that key, and you capture those funds.
There's also on other mechanism which you might want to check out - the orders endpoint adds more of a flow on top of auth / capture to allow you to have auth / capture more bound to a order processing - you can check out more on that here: https://devblog.paypal.com/rest-orders-api/
A few other notes. There are a whole series of products in the classic suite to also do 2) and 3). One of the best resources I like in the classic docs is the use case page at https://developer.paypal.com/webapps/developer/docs/classic/use-cases/ - it tends to help guide you based on real world scenarios.
I hope that all helps, and I'd be happy to follow up with more specifics if there is something that I missed from your scenario.
Jonathan LeBlanc (#jcleblanc)
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.
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.