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.
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'm checking the self-service API for flight booking. I got the process working ok: Flight Offers Search -> Flight Offers Price -> Flight Create Orders.
I've tried it and I got all the responses OK. I also understand I need to meet a few requirements to do the actual bookings in production.
What I don't understand is:
1) Where do I enter the payment information?
2) If the traveler is paying through credit card, is there an online form that is secure and compliant so I don't actually store the traveler's credit card info?
Thanks!
In Self-Service the booking works with a consolidator (an entity that will manage the ticketing with the airlines for you). You don't need to pass the payment method in the API call as you will have a contract with the consolidator and have this information directly provided to it. We are about to publish more documentation about it, as of today we open production only to some pilots, if you are interested you can contact us at developers#amadeus.com.
This part needs to be managed on your side, you will be the one handling the payment and the secure process to do it.
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 have a scenario where an application processes a payment and sends a portion of the payment to other providers. Part of the allure of PayPal is that these funds are available immediately via their PayPal Debit Card.
Are there any alternatives that offer an API for performing these transactions? I've seen mention of alternatives for this scenario (for example, in the following thread on the Dwolla site), but have never actually seen a company mentioned.
https://discuss.dwolla.com/t/will-dwolla-add-credit-cards-like-paypal/62
Try looking at: https://stripe.com/connect. It looks like it handles payment collection as well as sending payments to other providers. I've never used it myself though.
I have a situation where I am to bill the site users monthly. But the invoice amount that is raised depends on the the leads that our site generates for his business. For example if the user gets 5 leads from my site and I charge him $10 per lead, at the end of month he will be charged $50. similarly leads might vary each month so will the amount.
Now I cant store his cc/ paypal credentials on my site for security reasons nor can I pre bill him or ask him to take credits and then use it. Please let me know the way to handle this situation. How can I handle this using paypal?
There are a few different ways to handle this, but I would recommend Preapproved Payments, which are part of the Adaptive Payments API.
With this method your users would create a profile with you (using the Preapproval API) when they first create their account on your site. That will give you a preapproval key that you can store with your user account. Then in the future when you need to bill them you can use the Pay API with the preapproval key to process funds immediately without further approval.
If you're working with PHP my class library for PayPal will make these calls very simple for you. You would just use the Preapproval.php template to setup the profiles for people, and then use PayWithOptions.php to process payments using the preapproval key(s) accordingly.
If you end up using it and need more help you can contact me directly for support.