I have a hypothetical question about my PayPal developer account. Since the app I developed uses an API Username (myname-facilitator_api1.mydomain.com), API Password and API Signature to do the transactions, I am wondering what happens with the API access if my PayPal account for whatever reason becomes limited?
I've had my account limited in the past because I did a large withdrawal and PayPal asked me to send in documents to lift the limits ...but what happens during that time to the API access? Would customers also not be able to do transactions through my app during this time or how would it be affected?
There are multiple types of account limitations. For most limitations you can continue to accept payments. In other cases not.
If PayPal is uncertain about whether an account may have been compromised, or lacks a required piece of paperwork, they will generally only limit withdrawals so that the merchant can continue their business with as little impact as possible while they resolve the issue.
If PayPal determines that an account is fraudulent, or engaged in some type of enterprise for which PayPal cannot process the payments, they will block acceptance as well in order to protect the payers -- the alternative being to accept but then reverse all the transactions.
Usually, when your accounts becomes limited you can still receive payments. You can't withdraw though.
Related
I am studying how to implement a scenario with PayPal APIs where the customer confirms a PayPal subscription once and authorise all future payments. The amount is charged only when the user demands the service (i.e. like a food delivery app: the user agrees to the subscription once, and from that moment on he's never asked for confirmation each time he orders and confirms, the amount is automatically charged).
I know it could sound trivial (there are a lot of applications doing this) but actually I can't find that scenario in PayPal documentation.
Looks like the Subscription scenario only allows a cycle, which is not my case. In my scenario there is no cycle: the customer is charged only when consuming products or services (with variable amount from time to time).
Thanks in advance!
This requires reference transactions, which is an account feature that must be approved an enabled by PayPal. Contact your PayPal account manager or business support ( https://www.paypal.com/smarthelp/contact-us ) to explain the business need and request the feature. (Technical support will not enable the feature.)
As for the implementation, the only publicly documented API is Classic NVP. PayPal may give you guidance on integrating with some newer API, such as "v2" vault (not v1 vault)
I am currently upgrading an old system writing in JSF, which communicates with Paypal to create an "Acceptance term" for recurring payment, it generates a Token and when the client accepts the term, it creates an Agreement Id, later we use these to charge the client based on the services he used.
On the Paypal developer website, the Billing Agreement API is marked as deprecated, so I can´t work with it, they offer the Subscription as an alternative, but it doesn´t give the Agreement Id or the possibility to charge the user based on the usage, at least, not that I´ve seen.
Is there a way to create the Token and Agreement, or to use the Subscription (or other methods) to charge the user based on that?
eg. We offer a mobile plan for U$ 10, plus U$ 5 if the user sends more than 1000 messages, we first check if that happened, then we charge the user.
If the account is approved for reference transactions, and it sounds like it may be, you can use the Vault API which is in open beta, in conjunction with the orders API. See this example.
How shall I integrate custom shopping cart app with PayPal to accept indirect credit card payments without forcing buyers to register at PayPal?
There's a custom shopping cart web application and the task has been set to replace current credit/dept card payment with PayPal. The goal is to let the customers pay with their cards via PayPal. However, there are some constrains:
customers should enter their credit cards details (number, expiry date, secure code) not in shopping cart's page, but PayPal's page,
every payment must consists of authorization (blocking total sum) and subsequent capture if the ordered items are available and can be delivered,
customers aren't forced to create / login to PayPal account if they wish to pay via card.
The trouble is I'm really confused with the number of possible options at PayPal. The choice between REST API and Classic API isn't that problematic, but choosing the proper product from the whole list (like Classic API products or REST API products) isn't that obvious for PayPal newbie. Some other similar questions point to DoDirectPayment (but I don't know if it's the best choice) or suggest Website Payments Standard (I'm not sure if they're still available).
I was also considering Express Checkout, but the demo seems to force to create PayPal account.
ExpressCheckout is designed to be used in concert with a direct credit card acceptance method (such as PayPal's DoDirectPayment, or a non-PayPal credit card acceptance method), although it can be configured to also do guest payments. This is why the demos of the normal configuration handle only PayPal account creation; that's the normal usage.
One key question you need to ask yourself is whether you want to have access to the credit card information & be the "merchant of record" yourself or not.
YES: Doing this gives you the most flexibility, but will require you to go through some merchant vetting and carries some security obligations (PCI) even if you are using some solution which tries to distance you from the actual raw card numbers (e.g. collecting them via PayPal or Braintree code and immediatly encrypting & tokenizing them). In short: if you want full access to the card, then you have legal obligations re: handling that account access which technology can reduce but not eliminate.
NO: If you are content to always treat your customer's card information at arms length through PayPal, via the legal structure of a PayPal account (whether the user actually has a PayPal account or is just doing a "guest" payment on PayPal where they give PayPal their credit card for one-time use) then you can reduce your vetting & security constraints (no PCI requirements at all).
If you want (or need) access to the customer's card [YES above] then the "classic" API solutions are either DoDirectPayment (for when you collect the card info) or Hosted Sole Solution (for when PayPal collects the card info on their page). HSS meets all 3 of your requiremens above; DDP fails requirement #1.
If you can live with access to the customer & the payment but NOT the card account itself [NO above] then you can use Website Payments Standard, or EC with Guest Checkout option; both meet all three of your requirements.
All of the above solutions are not only still supported, but have tens or hundreds of thousands of integrated merchants and are the biggest/mainstream ways in which PayPal payments are handled.
If you prefer the newer products & are in the first category above (real card access, not guest payments) then you can also use Braintree or the RESTful APIs. These newer products don't yet have as much flexibility & coverage as the older products, but hey, less complexity can be a good thing as long as they have what you need. These products are generally designed around plugins for your web pages rather than entering card information on PayPal's site, however, so they don't meet your first requirement.
You can also do PayFlow (several variants) or Adaptive Payments or or or.... but in general I would advise picking either the most well-established or the new-and-growing options as being better supported & more future-proof.
Now that PayPal has acquired Braintree, the preferred integration method is v.zero. It is designed to be very easy to accept PayPal, Credit Cards and other options. (Venmo, Bitcoin, etc.)
I am using the standard paypal developer API (NVP) to get current inventory levels:
https://api-3t.paypal.com/nvp?METHOD=BMGetInventory&VERSION=95.0&USER=____&PWD=____&SIGNATURE=____&HOSTEDBUTTONID=_____
But, I have a concern... If the api is enabled and the key is compromised somehow, what is the worst case scenario? For example: it looks like it is possible to send payments using the API. Is there a second tier of verification of payments that happens outside the API?
I have spent around 30 minutes researching the topic without any clarity in terms of what kind of financial damage could be done if an api information is compromised.
If your PayPal API credentials are compromised then someone can make API calls on your behalf. This includes sending and/or withdrawing money from your account.
There are some ways to limit the permissions of a PayPal API credential on the pages where you set the credential up, so you might be able to create a key that is somewhat less dangerous. It has changed over time so I can't offer details; google and/or log in to your account and look.
And yes, PayPal has lots of fraud detection that it runs internally on payments, but they have no legal responsibility to figure out that your API has has been stolen and I would strongly recommend not relying on them to save your bacon in such a case.
Protect your keys, especially ones with access to your money.
I am so confused about the services and over here the paypal website also seems to be serving up 400's and 404s.
This is how the webpage looks for customers on my site when they are ready to pay:
As far as I know, I don't have Express Checkout, but I'm not sure if I have Website Payments Pro (my company created this account).
Now I have two questions:
1- This is just the sandbox. But on the real site, does this solution that give users the opportunity to pay by credit card? I've actually successfully done a credit card transaction in the sandbox, I'm just worried because I've heard that customers can only do direct credit card transactions in PayPal Website Payments Pro. The PayPal website is overloaded with information and I can't find my way around it to answer simple questions like this.
2- Is it possible to do negative testing for transactions on this page? Such as simulating the events that the user's credit card or Paypal account doesn't have enough balance? If it is possible, and I am using the ButtonManagerAPI, then is the technique below the correct way to go about it?
I put an error code in the amount variable that is passed on to IPN via via an NVP api call, like this (lots of value pairs in the middle excluded as irrelevant):
$nvpReq = "BUTTONCODE=HOSTED&..............&L_BUTTONVAR1=amount=".$err_code
EDIT
So it appears I have PayPal Website Payments Standard, which means I cannot incorporate cannot have credit card payment forms directly on my website, but customers have to be directed to PayPal. I'm fine with that, as long as customers have the option to pay with credit cards.
The screenshot looks like PayPal Standard, which is an HTML-only (non-API) integration.
Any regular business account that can receive money can make use of the Express Checkout API.. typically by authenticating with an API USER/PWD/SIGNATURE. For businesses with programming/development resources, EC is by far the recommended way to accept PayPal payments.
If you pass SOLUTIONTYPE=Sole in the initial SetExpressCheckout call, it will accept credit cards from "guest" customers who don't have a PayPal account, similar to the Standard screenshot you're displaying above.
The main reason to choose EC over Standard is that it's a much tighter handshake between your checkout software and PayPal's servers. With Standard's HTML-only, the customer is redirected away from your site and might not return to your site after a successful transaction is committed (they may stay on paypal.com and not click to return or their browser might crash before return --- whereas with EC the return to your site is built-in before anything touches the financial system)
With the recent beta of developer.paypal.com, all new sandbox Business accounts are full Pro accounts by default. Signing up for a live Pro account would be useful if, in addition to accepting PayPal payments, you wished to create a credit card entry form directly on your own site.
Here are some EC links for programmers:
https://tryit.paypal.com/guide/ec
https://paypal-labs.com/integrationwizard/ecpaypal/main.php
The button manager API is unlikely to be useful to you. And there are ways to do negative testing with the sandbox, but it's really not an important concern when you're still deciding on a product/API.