(All sensitive information will be replaced by *'s)
I'm having issues doing multiple authorizations on my order transaction through the paypal Express checkout. My order transaction looks as such:
PARTNER=*****&VENDOR=*****&USER=*****&PWD=*****&TENDER=P&TRXTYPE=O&ACTION=D&AMT=186.76&PAYERID[13]=*************&TOKEN=************&COMMENT1=w2279400&COMMENT2=
Which is approved:
RESULT=0&PNREF=B7PP7D067BC7&RESPMSG=Approved&AVSADDR=Y&AVSZIP=Y&TOKEN=*****&PAYERID=****&PPREF=*****&CORRELATIONID=ebf6245de4f4e&PAYMENTTYPE=None&PENDINGREASON=order
I then do my first authorization, followed by a delayed capture:
PARTNER=*****&VENDOR=*****&USER=*****&PWD=*****&TENDER=P&TRXTYPE=A&ORIGID=B7PP7D067BC7&AMT=92.32&COMMENT1=I2279400&COMMENT2=
PARTNER=*****&VENDOR=*****&USER=*****&PWD=*****&TENDER=P&TRXTYPE=D&ORIGID=*****&AMT=92.32&CAPTURECOMPLETE=N&COMMENT1=I2279400&COMMENT2=
These return approved. I then try an do my second authorization:
PARTNER=*****&VENDOR=*****&USER=*****&PWD=*****&TENDER=P&TRXTYPE=A&ORIGID=B7PP7D067BC7&AMT=94.44&COMMENT1=M2279400&COMMENT2=
However, this one fails with the following:
RESULT=12&PNREF=B7PP7D067BE3&RESPMSG=Declined: 10623-Maximum number of authorization allowed for the order is reached.
I can't seem to find anything really related to this message, other than it can be prompted by providing an amount of 106.23(which I'm clearly not doing)
Any help would be appreciated.
Thanks
Related
UPDATE: After troubleshooting on postman, I've found that start_date and end_date are nessesary fields. Everything now works fine on postman with 200 code. However I am still getting a 400 error on zapier...
I've managed to POST my API credentials and generate an access-token from the previous step in my zap sequence using a Webhook. I then used this token in a GET Webhook in the next step to try and retrieve transaction information (PayPal processing fee, etc...) using transaction_id and fields queries. The transaction ID I am using is being pulled from an actual Woocommerce order on our store, where the customer decided to use PayPal (I've also searched the ID in paypal and it is valid).
The reason I'm doing this is to try and pull extra information from PayPal- Such as payment processing fees about the transaction that Woocommerce does not provide through their app on Zapier.
Unfortunately I am seeing the following error 'The app returned "Invalid request - see details."'
I suspect it is because I am calling for the information incorrectly. In my mind, I am using transaction_id as the unique identifier for the specific transaction, and fields to retrieve all information regarding the transaction.
Error code in Zapier: "Status Code 400 Bad Request" - PayPal docs state: "INVALID_REQUEST. Request is not well-formed, syntactically incorrect, or violates schema"
Update: If you use this method to pull transaction information, you will need to set a delay long enough where the activity time on your paypal dashboard switches from a time to a date (meaning it is the next day). If you don't do this, no important information will be pulled.
I've figured it out. If anyone has a similar issue, set it up like this (probably use more dynamic dates though):
We use the https://financialdatafeed.platform.intuit.com/v1/accounts/account_id_goes_here/transactions endpoint on a recurring basis to fetch transactions for all of the accounts we sync. We've been using this stably for quite awhile now, across a wide variety of accounts spanning 100s of financial institutions. This works great.
However, occasionally we get a report from a user who claims that we're not receiving transactions that they know to exist. Our investigation protocol is as follows:
To ask the user if they see the transactions when they sign into their bank's web site directly
To ask them to confirm that the credentials they used on their bank's web site are precisely the ones that they entered when setting up credit card sync on our site
We then manually inspect the response body from the above mentioned URL, to make sure that the HTTPS response indicates HTTP 200 and has a non-error response body (our app catches these errors correctly, but if debugging mysteriously missing transactions, we inspect the response body visually).
We look to see whether we're successfully syncing transactions for any other user that relies on the same FI. If we are, we become confident that both the bank and Intuit APIs are well-behaved, and that the problem is on our end somehow.
We sometimes ask users to try the same FI in Mint, guessing that if it fails in Mint, that it might be a bank or FI issue.
Investigation steps 1-2-3-4-5 tease out the root cause of at least 99% of the times when a user emails us to say that we're not successfully receiving their transactions. However, the remaining 1% are the tricky ones.
Today I'm faced with a situation where a user sees the txns on their bank website, swears that they are using the same creds when adding the card to our site, the HTTP response from the endpoint is HTTP 200 but contains zero transactions, but yet when the user tries via Mint they successfully see transactions.
However, the particular FI (OnPoint Community Credit Union) is not one where I can do investigation step 4, because we have no other users that currently rely on that FI. Is it possible for someone at Intuit to check to see whether there is evidence that users relying on OnPoint Community Credit Union are currently, successfully, retrieving transactions from that particular FI?
Any other suggestions for how to further deduce whether the zero-transaction response is due to: (a) user error, (b) bank server responding incorrectly, (c) Intuit server responding incorrectly, vs (d) our app behaving incorrectly?
Can you please submit a support ticket to Intuit with the Account_ID that is missing the transactions so that we can diagnose the issue? The first place to start when diagnosing the issue is to look at the Agg_status_code to make sure that reflects a '0'. If we are unable to login due to invalid credentials or MFA might be a cause of the missing transactions. I can help diagnose though once a ticket is submitted.
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
Paypal provides access to a parameter called "SoftDescriptor" in a number of their payment request API calls, in the classic API (either NVP or SOAP). In theory, this parameter lets you send transaction-specific data along with your request, which will be passed along to the buyer's credit card statement.
This parameter is available on at least:
DoCapture
DoReferenceTransaction
DoExpressCheckoutPayment
I cannot, for the life of me, get this to work. None of these calls seem to set the softdescriptor for the initial descriptor (Which shows up in the bank statement while the charge is pending, before the payment posts). I've been waiting a few days for the payments to post to see if it will change at that point, but I'm skeptical.
Has anyone successfully used the SoftDescriptor? Did it require extra account setup?
This might be very late.
Soft Descriptors is supported only for US,UK and CA merchants.
Your account needs to be enabled for Soft Descriptor.You can contact Businesss/Customer Support to get this enabled.
https://developer.paypal.com/docs/classic/release-notes/merchant/PayPal_Merchant_API_Release_Notes_115/#softdescriptorforpro
Sorry, I know this is an old post, but I was looking for the same answer to the same question and I thought I would share what I found.
You should be able to use the following link to move past this error. In my case, I had a comma after the wrong right curly brace. Just copy and paste the example, in the aforementioned link, and change the values to meet your needs.
And I am about to post my own question about why the transaction amount is considered invalid
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!