I am hoping someone with experience can help here. We are sending people to PayPal using SetExpressCheckout and then billing them when they get back to our site. Unfortunately, we are seeing a 40% failure rate when we attempt to charge these users. I am including our request and responses below in the hopes that someone can spot a variable that may be causing some trouble for us.
Thanks!
REQUEST TO PAYPAL TO SET EXPRESS CHECKOUT:
SetExpressCheckoutReq:
SetExpressCheckoutRequest:
Version: 116.0
SetExpressCheckoutRequestDetails:
MaxAmount currencyID="USD”: 100
ReqConfirmShipping: 0
NoShipping: 1
AddressOverride: 0
SolutionType: Sole
BuyerEmail: xxx
BillingAgreementDetails:
BillingType: MerchantInitiatedBillingSingleAgreement
BillingAgreementDescription: Billing Agreement
PaymentDetails:
OrderTotal currencyID="USD”:0
ItemTotal currencyID="USD”: 0
ButtonSource: PayPal_SDK
PaymentDetailsItem:
Name: Subscription
Quantity: 1
Amount currencyID="USD”:0
PaymentDetailsItem:
PaymentAction: Authorization
RESPONSE:
Timestamp: 2015-06-30T02:35:29Z
Ack: Success
CorrelationID: xxx
Version: 116.0
Build: 16684246
Token: XXX
BILLING ATTEMPT:
DoReferenceTransactionRequest:
Version: 53.0
DoReferenceTransactionRequestDetails:
ReferenceID: EC-1WA3806198386283U
PaymentAction: Sale
PaymentType: Any
PaymentDetails:
OrderTotal currencyID='USD’: 14.95
OrderDescription: Subscription
NotifyURL: xxx
ReqConfirmShipping: 0
ERROR RESPONSE:
Short Message : Transaction cannot complete.
Long Message:Instruct the customer to retry the transaction using an alternative payment method from the customers PayPal wallet. The transaction did not complete with the customers selected payment method.
ErrorCode:10417
SeverityCode: Error
CorrelationId:907fc42ce9669
Build:17098556
Ip:
A few things to change with your parameters, but also see the last item:
You are requesting version 116 (relatively modern) for SetEC and version 56 (circa 2005, ie 10 years old!!) for DoEC. It's unlikely that this is causing your issues, but I would still fix it :)
Your SetEC is for a biling agreement but your DoEC is for a sale transaction. Don't mix and match these, it screws up PayPal's ability to set the funding correctly. If you are just doing a sale, remove the billing agreement from the SetEC and....
update your SetEC to specify a nonzero amount, hopefully close (within +- 20%) of your actual DoEC amount. PayPal may be defaulting customers to the wrong funding source, or letting them through without correcting fixable account issues (such as an expired or otherwise unusable credit card) because you told PayPal that the payment would be for $0, and only when you actually DoEC for $14 does PayPal discover that the buyer doesn't have the money for you.
And finally:
There can be many things that cause 10417 -- it is a risk response, meaning that PayPal is deciding to decline the transaction.
See e.g. Paypal accounts funded by credit cards = 10417 error, in which another seller was having lots of declines because they were selling in a very high risk category. Not sure what your account is set up as, but something like this could be affecting you... if you continue getting a 40% rejection rate with natural user traffic after cleaning up your API calls I would contact PayPal support.
Related
We require reference transactions via PayPal to bill customers monthly with varying amounts.
e.g. first month is $30, second month may be $35, third month may be $25 etc
So far this seems to be the best approach: https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/
I am using the PayPal recommended SDK from this page: https://developer.paypal.com/docs/classic/api/nvpsoap-sdks/
and using the ExpressCheckout Method. (paypal/merchant-sdk-php installed via composer)
We have a free PayPal business account.
Testing via Sandbox I am able to:
Get a token (SetExpressCheckout) - category->Digital, billingAgreement, Type=Sale
forward customer to sandbox paypal login
Confirm the payment
redirect back to our system (returnUrl)
Process the payment (GetExpressTocket + doExpressCheckout)
Questions:
Does the PayPal business account require any switch/status/upgrade to enable Reference transactions on the live environment?
How do you setup a $0 billing agreement to invoice an amount later in the month? When passing a 0 amount in step 1 above and error is displayed
Item name, amount and quantity are required if item category is
provided, ErrorCode 10003
This contradicts to documentation https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/#setting-up-a-billing-agreement-before-payment which states to set the amount to 0...?
UPDATE: Removing the setting $itemDetails->ItemCategory = 'Digital'; solved the $0 amount issue.
Billing ID is not returned even though I've passed the BillingAgreement data
// Billing agreement details
$billingAgreementDetails = new BillingAgreementDetailsType('MerchantInitiatedBillingSingleAgreement');
$billingAgreementDetails->BillingAgreementDescription = $billingAgreementTxt;
$setECReqDetails->BillingAgreementDetails = array($billingAgreementDetails);
I know there are a few questions within the post but I believe they are all related to the scope of 'Reference Transactions' within PayPal.
I'm looking for recommendations on approach and explanations to the contradictions in documentation. (or if I'm doing something wrong then happy to hear it)
To answer your question:
1) Does the PayPal business account require any switch/status/upgrade to enable Reference transactions on the live environment?
If you are receive an error when calling for Reference Transaction, probably that the setting is turned off in your account. You will need to contact PayPal Business Support team to enable it.
2) Billing ID is not returned.
To setup billing agreement, you will need to pass paymentaction=authorization in SetExpressCheckout request. You will not be able to setup billing agreement if you set the paymentaction as sale.
I looked over the documentation here https://developer.paypal.com/docs/api/ but I'm still not finding the right request that will return what tier of Merchant Rate a particular user has.
For reference: Paypal can charge $.30/transaction and (2.7%, 2.5%, or 2.3%) of the dollar-value of a transaction. I'd like to request the current tier a particular merchant is being charged so I can run an estimated calculation on newly authorized or pending authorization transactions in my app before Paypal actually finishes processing and charging the fee.
The other option (more painful) is to run a reverse calculation on the most recently completed transaction* to identify the most recent fees being charged, then store that as the current tier and update it on a schedule.
Anyone tried to get this info or found a workaround successfully?
*example calculation
If the most recently completed gross transaction amount was 100,
Fees charged were 3, net settlement was 97
Then 3.00 - .30 = $2.70
2.70/100 = .027
Therefore, current fee tier is 2.7 percent + .30
Then, I'd store that info.
My use case: buyer buys service from seller, our app facilitates and guaranties the transaction. It should work in the way that buyer sends the money to us, we check if buyer received the service, in that case we send the money to seller. Otherwise we refund the buyer. Important is to have 2 payments solutions for the buyer: paypal account and card payment without account. The whole use case is international.
I'm testing this in sandbox environment.
Possible solutions:
Adaptive payments - Delayed chained payments:
Works fine. Disadvantage is that the seller must grant us permission so that the refund works. The problem here is that the permission api is under maintenance, so i am waiting for all the changes https://developer.paypal.com/docs/classic/permissions-service/integration-guide/PermissionsWhatsNew/ . Is this big deal?
Express checkout Authorize/Capture + Mass Pay:
Works OK. Advantage here is that in case of refund (void after authorize) we don't have to pay the fee. Disadvantage here is that I'm not sure if authorize holds the funds, so that even buyer without account paying with card cannot touch the money and I can capture them in 3 days. Another issue is that when I authorize 40$ from PayPal account with 30$ balance, I capture the whole 40$. How come?
I have no previous experience with PayPal I now the app should work on international scale. Please if you have any tips, articles or practical experience with this use case share it!
EDIT:
Delayed Chained Payment is great. I solved the issue by making my application the secondary receiver and the seller primary one. Seller must grant a permision to my app in case of refunds, but there is no better way.
However, now the issue is that when buyer pays without account (Guest Payment - with card) all receivers must be Business or Premier account holders:
Each receiver of a guest payment must be a verified PayPal business or premier account holder.
Source: https://developer.paypal.com/docs/classic/api/adaptive-payments/Pay_API_Operation/
The issue is that in sanbox it works even if the primary receiver (seller) is NOT Business or Premiere account. What is wrong?
1) Do you have yourself set as the primary receiver? If so, I don't think you would need to have permissions granted unless you had already run ExecutePayment to push the money to the secondary receiver account. If you're refunding before that happens you shouldn't need permissions (though I haven't tested this specifically, so I could be wrong.)
2) Regarding the fee, if you refund a payment that went through Adaptive then PayPal would refund the fee back to you, so you're not really gaining anything here as far as that goes.
The authorizations can be tricky. I theory, the authorized funds should be guaranteed for 3 days, but you still capture within 30 days (or maybe 60) even though it may or may not have funds available at that point (it would simply succeed or fail).
You could run a Reauthorization after the first 3 days to get yourself an additional 3 days of guaranteed funds, but I don't think you can do that more than once.
Much of that depends on the card issuing banks, though. Even though PayPal's docs may specify certain things regarding how authorizations work, if the card issuing bank has different rules associated with their credit cards that could throw things off.
As for why a $40 auth would work when the PayPal balance is only $30, I think that may be because of secondary funding sources. If you have bank account and/or credit cards setup in the account, PayPal would assume it can pull from those sources when the time comes to capture if the PayPal funds alone don't cover it. Depending on your use-case this may or may not be ideal.
You are mixing multiple concepts with this question. There are different PayPal PAYMENT products (adaptive with chained payments vs express checkout) and then there is the question of authorizations vs immediate payments.
Agree with Andrew that fees in the refund case is not the right basis to choose a solution. Much more significant is what the sender & receivers will see in their accounts (payments to/from you, or from/to the other party?), simplicity/reliability of the overall system (can an error on your side cause failed or multiple payments?), liability, and even regulatory questions (e.g., are you acting as an escrow service?).
If PayPal gives you an auth from a PayPal buyer it means that PayPal guarantees (with certain very limited exceptions) that it will honor a capture of those funds within the specified time and amount limits (which can vary with the specific scenario). PayPal might make that guarantee based on the sender's balance, credit cards, bank accounts, or combination of factors. You as the recipient needn't care - that is between PayPal and the buyer. (And it's PayPal's limits/conditions which apply to that auth, NOT the conditions of the sender's underlying credit card/bank/etc; PayPal protects you from that complexity.)
In contrast if the auth is from a card network rather than a PayPal account (ie the user gives card info rather than using a PP account, whether or not PayPal is your payment processor), then that network specifies and controls the conditions of the auth.
PS: if you are waiting for Adaptive Payments changes, you may have a long wait. Release 89 was quite some time ago and PayPal's priorities are on the RESTful APIs, not Adaptive.
Using the parallel payments paypal api. If user 1 makes a payment to user 2, I make a check using the api to make sure paypal returns the payment details as COMPLETED.
How long does paypal keep that COMPLETED payment record? Do they keep it indefinitely, or do they delete it after a while? I ask because I am at the stage of development where I need to decide if I should rely on paypal keeping that record indefinitely, or if I should create a record on my server that the payment has been completed, or if I should always check if the payment has been marked as COMPLETED by querying paypal?
The only reason why I "want" to check via paypal, is if the payment is ever returned to user1 as REFUNDED or PARITALLY_REFUNDED when paypal is queried using their apis. I would want to act accordingly in such situations.
It's not too much of an issue if the status is REFUNDED or PARTIALLY_REFUNDED as apparently people can't get refunds if they don't open a case with paypal before 45 days are up. I am more concerned about the REVERSED status, which can apparently happen any time, even after 45 days which is beyond paypal's control, as it is done by the credit card companies, if the user pays by credit card...
Using the PaymentDetails request I was able to pull my oldest Adaptive Payment transaction, which was over 60 days old and had no problems pulling it up using the transactionId field. It should be able to pull up payments as long as they are listed in the PayPal account (currently forever.)
This will work using the payKey field also if you are storing that instead of transactionId, however the transactionId is displayed in your PayPal account and is sent with IPN responses.
Well I asked though the paypal site, but have got no answer. I got the famous email with "Your question has been received. To review the status of your ticket, click on the link below." with no link in it. So I'm hoping I can get an answer here.
This is what I sent them:
It appears you have multiple APIs available and I'm having a hard time figuring out what the each API is capable of doing exactly. I want to create a site that in short, brings buyers and seller together. Here is what I am looking for:
Buyer and Seller make an agreement through site.
Buyer sends money, seller is unable to touch it yet though. (Basically can paypal secure a payment?)
Seller gets notice of money sent and notice to ship product ship product.
Alternative paths for step 4:
Buyer gets product and there are no issues, the buyer confirms the transaction and payment is released to the seller and a set % is sent to me. (Can paypal split payments?)
Seller never ships product or problem arise in shipping that cannot be resolved, paypal returns money to buyer without penalty. (Can paypal return funds without penalty?)
Product arrives, but has issues. There will be set penalties for said issues. Penalities are returned to the buyer, then rest is sent to seller and set % sent to me. (can paypal enact a penalty?)
Any general information or answers to my specific questions would be greatly appreciated. thank you for your time.
For #2, since you're the service provider, you'll be liable for product delivery. Paypal won't do it for you.
An ideal workflow would be:
Your buyers pay you
You withold the payment
Buyer okays the shipment
You keep your cut and pay the rest to the seller
If you have to refund your buyer (order cancellation, or some other reason), you can use paypal's refund api
To summarize, paypal is just a payment processor and would ensure that payment reaches from endpoint A to endpoint B. How you use paypal for your particular use cases is totally upto you.