I finished my PayPal REST API integration yesterday for executing simple payments through my website. My script does the following things:
gets a bearer token
creates a payment (allowing paypal as the only payment method)
sends to user to PayPal for authorisation
executes the payment
This was all working perfectly in the Sandbox yesterday.
Today I tried it (still in the Sandbox) and the execute command is returning an "INTERNAL_SERVICE_ERROR" message. The debug_id from my most recent attempt was 93a4116223d6e.
What is particularly strange is that the payment has been processed correctly. When I log in to the sandbox accounts for the buyer and seller the transaction shows up there as usual.
Any idea why I am suddenly getting these error messages?
I have also a problem with the Sandbox environment.
Payments with an US account returns an INTERNAL SERVICE ERROR, but with other EU accounts the payments are completed.
Using PayPal as payment method.
It seems to have stopped doing it now. I am putting this one down to an error at PayPal's end. It only seemed to last for a day or two.
Related
I have a Paypal Digital Goods Express payment form created using their wizard.
When I use our live account it works fine. But when I use the sandbox Business (Seller) account I created, when a user clicks on the 'Buy' button, the popup window appears with only this message:
SetExpressCheckout API call failed. Detailed Error Message: Short Error Message: Error Code: Error Severity Code:
I did some research and saw this article:
https://www.paypal-knowledge.com/infocenter/index?page=content&widgetview=true&id=FAQ1914&viewlocale=en_EN
It suggests that our hosting company needs to update their PHP/TLS, but I did the Curl test and it properly returns a 200 OK.
I also saw this Stackoverflow article:
Paypal "SetExpressCheckout" API method has stopped working with sandbox seller account
...where the problem was the wrong sandbox endpoint, but I've made sure that the endpoint is indeed:
https://api-3t.sandbox.paypal.com/nvp
...and it still doesn't work.
I've tried clearing my browser cache, using different computers to test and all with the same result.
Any ideas?
did you enable Digital Goods feature on your sandbox accounts?
If you have not enabled it on your sandbox account, please contact MTS(Merchant Technical Support)
https://www.paypal-techsupport.com/app/ask
to toggle it for your sandbox account.
Paypal newbie here. I am using the .net sdk to call PayPal's rest api in the Sandbox environment. I am trying to test a batch payout(Mass Payment).
Issue 1. The sandbox "facilitator" account which came pre-created has a zero balance. I cant seem to find any way to get some money in the account so that i can test payouts. If i create a new business account, i get to specify an opening balance, but when i try to do payouts using this new account, i get back a 403 forbidden response when i try to payout even though i am able to get a token successfully.
Issue 2: Using the facilitator account, i am able to submit a payout request, but its behavior seems to have changed since a couple of day ago. A few days ago, all payout request used to be DECLINED and would show up on the transactions list on the sandbox site. I assumed they were getting DECLINED because the balance was zero. Since yesterday, all payout transactions via the facilitator account stays in PENDING stage and they do not show up on the transaction list. A Payment/Get request for the payout_batch_id always returns back as pending even aftter a day, but theres no sign of those transactions on the sandbox site.
1 - Creating a fresh account and giving it an opening balance is correct, and that should work just fine for you to test MassPay. If you're getting a 403 error that sounds like a problem with your API endpoint or something. Need to see a sample of the API request/response to know more on that.
2 - Again, need to see a sample of the API request/response that you're getting to know more here. My MassPay transactions in the sandbox work just fine. Here's an example. You'll see the request and response data there, showing it was successful. Then when I go look at the separate accounts I see the money as expected.
We have this website that was running since September 2013 and relying on paypal IPN for user registration. However, this week we got a report from the client where 3 users was able to pay through paypal but was not registered into the site.
We temporary changed the paypal email('business' field) from the client's to another paypal account. Went through the process of registration and the IPN was successfully delivered. The user was created in the system, the IPN transaction was logged into our system. When we tried to changed it back to the client's paypal email account, but unfortunately the IPN did not reached through our system.
Here are some questions that I have in mind
Does the type of paypal account (ie. business or personal account) matter when sending and receiving IPNs? Could this be a possibility? (even though last year it was working perfectly fine with the client's paypal account)
We've been receiving this paypal email (below) for the past months. That email was appearing after a few months when we opened the site and we didn't even changed a single code from our IPN listener. Could this be the reason why the IPN was not sent when we use the client's paypal account? However, we always use the notify_url field since we have multiple IPN listeners.
>Please check your server that handles PayPal Instant Payment
>Notifications (IPN). IPNs sent to the following URL(s) are failing:
>
>http://<site>/payment/postback/
>
>If you do not recognize this URL, you may be using a service provider
>that is using IPN on your behalf. Please contact your service provider
>with the above information. If this problem continues, IPNs may be
>disabled for your account.
thanks,
Your IPN script is not completing successfully, so PayPal's server is not getting a 200 result back, which causes it to send repeat IPN's and will eventually disable itself as the message says.
Your web server logs should provide the info you need. Check there to see the history of the IPN script getting hit and you'll probably find some 500 results. Those should also provide the actual error that happened so you can get it resolved.
It's possible that some IPN's are working just fine but others are failing based on certain characters in payer information or other similar issues. You need to get all of that worked out in your IPN script so it can handle anything thrown at it.
On the introduction of PayPal Invoicing API documentation it states that.
PayPal sends IPN messages for invoice payments and for invoices
cancelled by the buyer.
But I've found this is not the case. IPN for invoice payment, cancel or other operation never get sent from PayPal (I have checked and confirmed it from IPN history page).
Worth Mentioning
Invoices are being created via Invoicing API successfully without any warning.
I am working on Sandbox and Creating for Third Party Merchant.
I do understand that paypal doesn't send IPN for api operation changes.
The IPN listener is working fine and I have successful implementation for subscription api with IPN.
Update
Today I tried the whole process with Live PayPal account other than sandbox account and I still not getting any IPN. So, I guess I am doing something wrong or Invoicing API is broken (which I highly doubt).
Which also makes me wonder about some additional questions:
I (merchant #1) has the permission information form merchant #2 for sending invoice to their behalf.
I have setup IPN to my IPN listener URL.
merchant #2 do not have IPN setup to my listener URL.
So, when Invoice that I created for merchant #2, Do I get IPN?
OR, merchant #2 also needs to setup their IPN url pointing to my listener URL?
IPN is get send from the account that receiving payment as #effone mentioned in comment. So, it seems I was confused from paypal documentation.
Answer: The IPN url from merchant #2 will need to setup in order to get notification about invoice payment. merchant #1 account who sending the invoice behalf of merchant #2 will not send any IPN as the payment isn't involves merchant #1
Way I see it, this is not a proper solution to create an invoice management system. As if I have 1000's of user they all need to set their IPN url to mine in order to get the application work correctly (aka, setting invoices as paid when they gets paid)
Your question reads strangely, because you say the IPN is working fine, then in your update, you say you're trying it in your live PayPal account. It sounds like it's working on the Sandbox, but not in production?
If this is the case:
Did you activate the IPN under your Production (Live) Paypal account?
Do you have the IPN URL for this?
Are you seeing the IPN being logged under the Production (Live) PayPal site?
If No -> it's been a while since I've worked with this, but there used to be an interface where you could send an IPN test- have you tried that?
If Yes -> make a bare bones listener- just a page that logs that it was hit, then add logic to it.
hth
When a paypal recurring payment is suspend an IPN with either one of the following txn_type will be sent
recurring_payment_suspended
recurring_payment_suspended_due_to_max_failed_payment
Question: Is there an IPN to notify of a re-activation, like:
recurring_payment_reactivated
I could not find any info on SO, Google and https://www.x.com/developers/paypal/documentation-tools/ipn/integration-guide/IPNandPDTVariables
Or does anyone know why PayPal would provide an IPN to tell us when a recurring payment is suspended
but not when its re-activated.
I just tested this scenario on the sandbox. I created a new profile using CreateRecurringPaymentsProfile and I immediately got the recurring_payment_profile_created IPN as expected.
I then suspended the profile using ManageRecurringPaymentsProfileStatus and immediately got the recurring_payment_suspended IPN as expected.
I then reactivated the profile using ManageRecurringPaymentsProfileStatus, but I did NOT get any new IPN from this action.
Based on those findings I would say, no, you will not get one in production either.
That said, I always recommend using the GetRecurringPaymentsProfileDetails API to check the current status of a profile any time users log in to a paid area of your site (or attempt to access anything that requires a valid profile.)