I am building a payment system where a user can make a payment against an orderId
I want to make sure that only one payment gets through (gets captured)
The payment flow is like this:
1- User clicks on Paypal button
2- a Transaction PENDING_PAYMENT gets created for the user with orderId
3- User pays in Paypal
4- Paypal sends webhook and marks the payment as AUTHORIZED
5- The system CAPTURES the payment
as you see, the user can open multiple Paypal pages and pay all of them at the same time, there's no way for me to prevent this, but I want to be able to CAPTURE only one of these payments. (so I can automatically refund the rest of the payments)
I really appreciate any help, Thank you in advance.
When you set up the PayPal transaction for approval, pass a unique invoice_id to PayPal that has never before been used for a successful payment on that PayPal account. This could be your orderId, perhaps with some additional prefix added if desired. (For instance if you had multiple storefronts on the same PayPal account that might use the same order numbers, a prefix of 3 letters and a dash indicating the store name is a typical choice)
By default, PayPal accounts prevent (block) any subsequent payments for an invoice_id that was previously used for a successful payment on that account -- precisely to prevent accidental payments for the same thing, as is your use case.
Related
I am making a system in which user permits pre-approval of amount. I've used pre-approval with chained payment. But the problem is that my customer gets redirected to PayPal site and also he/she must have a PayPal account or need to create one. So can i make pre-approval payment using PayPal website payment pro? So my customers will not get redirected to PayPal account. And the process becomes more fast? Note :- I don't want to use authorization and capture method. Thanks.
Edit
One more question :- If i make the website in the UK and the currency in GBP, can I still use the American Paypal account for this?
Auth and Capture is what you're asking for, but then you say you don't want it..?? That's what gives you the functionality you're after, though.
You could do a $0 auth and then run DoReferenceTransaction when you're ready to process the payment as opposed to capturing an actual auth if you want.
Those are your only options when working with Pro, though, and it would give you the same sort of preapproval experience for the buyer.
Here are the steps to accomplish what you're after.
Use DoDirectPayment to run a $0 Authorization (card verification). Users will enter their credit card details directly into a form on your site without any redirection to PayPal (and without any knowledge PayPal is being used at all unless you notify them some way.)
Save the transaction ID that you get form this card verification into your transaction history for the customer in your database. This ID is what will be used to process future payments using that credit card.
When you're ready to process a payment for this customer, pull the ID out of the database and use it with a DoReferenceTransaction request to process any amount you need to.
So the card verification is your preapproval, and then running reference transactions are the same as running Pay requests with a Preapproval key. Both methods accomplish the same thing, but one is with direct credit cards and the other is not.
If you're using PHP you can use this PayPal PHP SDK to make all of the API calls very quick and easy for you. If you're using some other language then there are SDKs available for those as well I'm sure.
Please correct me if i am wrong, #Andrew Angell #Ved Pandya
Auth and Capture or Capture payments later method allows you to do direct payment, but it comes with additional charges, which might not suitable for crowdfunding model as refund/ cancel payment is very frequent
Auth and Capture: You are required to pay $0.30 for each "Card Verification Transactions"
Capture payments later: You are required to pay $0.30 for each "Uncaptured Authorization" that you triggered
https://www.paypal.com/us/webapps/mpp/merchant-fees
My customer is using recurring payment. I have two problem to resolve:
Case 1 : My a customer have some recurring bill. This want change these recurring bill to other paypal account. Is there paypal api to support to delete recurring bills in current account and renew thes bills to new account.
Case 2 : If due to payment,customer's paypal account is not enough money, my system will lock some customer's function. I want paypal call my system 's function to handle this. Is there a way to resolve my problem.
1) You can use ManageRecurringPaymentsProfileStatus to cancel/suspend the profile on the existing account. You'll need to have the user go through the process of creating the new profile on the new account, but this can be done via the use of CreateRecurringPaymentsProfile.
If you happen to be working with PHP my class library for PayPal will make these calls very simple for you.
2) You'll want to utilize Instant Payment Notification (IPN) to automate the management of the profiles. PayPal will POST transaction data in real-time to a listener script that you have setup on your web server. This script can receive that data and then update your database, send out email notifications, hit 3rd party services, or whatever you want to do from within it.
PayPal will send an IPN when a profile is created, updated, suspended, canceled, as well as when payments are completed, failed, skipped, etc.
Current Status
I'm quite new to PayPal and I'm currently integrating chained adaptive payments on our website. Already successfully called the PAY API call via the .NET SDK. Money (sandbox enviroment) will be correctly transferred to each participants of this payment (sender, primary and secondary receiver).
Requirement
My goal is to execute vital tasks after the payment is successful (update DB, send mail, ...) or has been cancelled (clean up stuff, ...).
Possible solutions
1)
First approach was to create the payment with actionType set to CREATE, redirect the user to paypal.com (wait for approval), redirect user back to website and execute the payment and then perform the vital tasks. But it seems not to work, the payment will be paid and is COMPLETED before the second redirect.
2)
Another possible solution would be to get the preapproval from the user, redirect back to the website and execute the payment. Haven't tried this solution yet, don't think that this is best practice.
3)
Call PAY with actionType set to "PAY" and wait for IPN. Haven't tried that either, because it is quite difficult to test it locally (even though I've already found this question: Paypal Sandbox Test Tool IPN Simulator in Localhost).
Question(s)
Which solution is best practice? I guess the recommended solution would be to wait for an IPN?
If I'am using IPN how long is the average response time after a payment has been completed? Seconds, minutes, hours? I know it depends on the load of the PayPal webservers and that there are 15 retries over 4 days, but what are some real world numbers?
Can I store additional information (e.g. UserId) about the sender in a payment (besides the memo field) which I then get back in an IPN?
Here is how I do it.
When I'm going to initiate PayPal payment (before I send a request to obtain TOKEN), I create new transaction in my database and set it's status to PENDING. In transaction table I also have userID column, which is foreign key to user table. This way I connect transaction with user.
When transaction is created in my table, I use transactionId value, and save it to PHP $_SESSION variable.
Please note that if you want to support recurring payments, you can provide transactionId to PayPal. This you can do by setting:
"PAYMENTREQUEST_0_INVNUM"=>$transaction->id.
This value will be sent when PayPal sends you IPN request after recurring payment happens.
Go back now to the story
User is redirected to PayPal, and when user fills PayPal username and password, and when user confirms payment details, user will be redirected back to your website and you have to call DoExpressCheckoutPayment to make payment itself.
If the result of DoExpressCheckoutPayment API call is success, that means that transaction was successful and you have money. At this point, you can send email, notifications, or any other important action.
$transactionResponse=$paypal->request("DoExpressCheckoutPayment",$requestParams);//Execute transaction
if(is_array($transactionResponse) && $transactionResponse["ACK"]=="Success")//Payment was successfull
{
//Send email
//Notify user
//Do other important changes in database, for example mark this transaction as successful
Transactions()::model()->updateByPk($_SESSION['transactionId'],array('status'=>'SUCCESS');
}
IMPORTANT NOTE FOR RECURRING PAYMENTS: PayPal can/will send you several IPN requests for the same recurring transaction which means that you have to add logic which will chekc weather specific IPN request is already processed or not. Usually I do it in a way to check weather status of my transaction with transactionId is 'PENDING' or 'SUCCESSFUL'.
If I have a Visa card number saved in my database, is there a way I can charge that Visa automatically through the PayPal API without the user having to enter anything? We want to keep this site as easy and hassle-free to use as possible. It would be a variable amount, based on how they use the site.
(Don't worry, proper disclaimers will be in place, and the user will be notified)
What about these "recurring payments"? That way I don't have to store the CC info on my website, but do they allow variable amounts that I could periodically send to PayPal?
Yes, you can.
Look at Direct Payments:
1 On your website, the customer
chooses to pay with a credit card and
enters the credit card number and
other details.
2 The customer reviews the order.
3 When your customer clicks “Pay” to
place the order, you call a PayPal API
to request payment, and the payment
transaction is initiated. Note: The
customer does not see this step.
PayPal does not send your customer a
recipt for the payment.
4 You transfer your customer to your
order confirmation page.
The payment is performed without redirecting the customer to PP site, so it's up to you to request CC data from the customer and submit them to PP API.
I wanted to use Paypal's IPN service to verify payments for a recurring subscription charge for my website. How do you tie the IPN confirmations to a user in your site?
The IPN confirmation message has a name, email, paypal ID, recurring payment ID, but it seems to not give a unique identifier since I don't know where the paypal ID or recurring payment id comes from and it may not be trivial to uniquely match up the name/email that a user has on their paypal account (or entered there) with the name/email I have for them on my site (there may be many John Smith's and the person may choose to use a different email.)
1) When I send the initial payment request to Paypal, I can attach a unique UUID in the URL I ask them to send back to me, so if I save that unique ID for that user I can match that payment confirmation to the user who initiated it. Am I making that harder than it is? Is there an easier way?
2) Also, for a recurring/subscription charge, does paypal always use the URL I specified with the initial payment initiation? Does anyone have practical experience using the recurring Paypal payments with IPN's, does it reuse that unique URL? Or do I have to associate the Paypal ID's with the user after the first recurring payment is received?
Attaching unique data to the payment request is pretty much the accepted way to do it.
I don't have any experience with recurring charges.
I recently also set up some reoccurring payments with Paypal.
I actually wanted people to register as members after paying for the subscription, if they wanted to. As having to sign up as a member could add some friction to the sale process. So I don't send any user info along with the Subscribe button.
What my IPN script does is generate a unique activation code tied to the Paypal subscriptionID in the Activations table, then it sends this code to whoever paid for the subscription, with instructions on how to activate.
At the point of activation, you need to register or login. At this point the userID is added to the relevant row in the Activations table.
When the EndOfTerm IPN notification comes in the IPN script looks up the userID from the Activations table based on the SubscriberID given in the IPN. Then I can do whatever I need to do to that user to disable their subscription.
At all time the URL of the IPN script remains the same.
1) You can send an 'item_number' parameter with the initial subscription setup, which will get passed back to you. I'd suggest embedding an identification token in it.
2) If you mean the 'return' parameter, no, that's for sending the user to at the conclusion of the subscription setup. The renewal is automatic and doesn't 'ping' that page.
1) You want to be using the item_number parameter. Set this in your HTML form shown to the customer, and it will be returned to you by the paypal IPN, so you can put a database row ID in here, and use it to match up to the right person later.