I've suddenly been getting this error since yesterday when paying multiple accounts: "Invalid request: We had to block this payment because it didn't comply with regulatory requirements".
This was working fine last week (and have been so for a long time) but started returning this error yesterday. I can't find any info about it and what needs to be done, can anyone help?
Without more information about the accounts involved and the full error message returned, it's only possible to guess that it might have to do with the country or currency of the accounts involved.
Contact PayPal for support
I have a web site thats been operating for months, if not years. It takes payments via PayPal. IPNs are used to track the payment status against an order.
If the paypal account owner issues a refund, the IPN from that is tracked, and the order updated with the amount refunded.
Now: The problem: This was all working in February 2015. But since then I have made 4 refunds (buy logging into the PayPal website and refunding). Each one was days apart. In each case they were partial refunds.
In all cases the monies have reached the recipient, and logged transactions IDs etc in PayPal.
The first one, I never received the IPN.
The second one I did received the IPN (and decided the first one must have been a glitch, unusal though it would seem)
However the third and fourth also have not generated an IPN that I received.
From looking at the Apache logs, there appears to not have been even an attempt from notify.paypal.com that Apache received.
So I am much puzzled, have googled around but not found anything. Can anyone suggest what I have missed that have caused these IPNs to stop?
Perhaps I should add that I continue to receive all the payment notification IPNs just fine. It seems to be just the refunds that I miss.
I thought at one time there was a flag about IPNs in settings, but I can't see it anywhere in the new web interface.
Regards
Monathan
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.
I'm getting this intermittent message on checkout in BigCommerce.
Your financial institution has indicated that it could not successfully authenticate this transaction. To protect against unauthorized use, this card cannot be used to complete your purchase. You may complete the purchase by selecting another form of payment or use a different card.
My API is correct with Paypal Payments Pro, Check out works and then doesn't work. Tried a few cards, sometimes the card worked, and sometimes it didn't. Here is the error message.
Your financial institution has indicated that it could not successfully authenticate this transaction. To protect against unauthorized use, this card cannot be used to complete your purchase. You may complete the purchase by selecting another form of payment or use a different card.
I have the same account setup on another BigCommerce site and never had a problem.
If you have another BigCommerce site and are using the PayPal account, make sure that your starting invoice numbers are far enough apart, otherwise you will be sending duplicate invoice numbers to PayPal and end they'll return an error. I was getting the same error, and I just set had to set one of my store's starting invoice number (under store settings/misc) to a really high number. This fixed the problem. Thanks BigCommerce tech support guy!
(You should be able to see what error you are getting by going through your store logs)
I'd like to test paypal subscription IPNs, both the ones received when a subscription is created, and the ones sent later with the next payment (such as monthly if the subscription is $x per month).
However I'd prefer not to wait a month or a day to receive the second IPN. Is there a way to have an IPN sent quicker, such as hourly, using paypal or their sandbox?
On the documentation it says you can only specify years, months, days, and weeks as the subscription period.
PayPal's developer support and documentation is an embarrassment to them. But this particular limitation isn't as debilitating as it seems at first blush.
For testing, define your recurring payment to not have a free trial. When you create a new subscription, your server will receive two IPN messages in quick succession, one to create the subscription and the second to apply a payment. That's basically all you need to test.
If you have a free trial, you'll get basically the same pair of messages, just with a trial period between them. :)
The first message ("create subscription") will look something like this. Note the 'txn_type' -- that's the key bit of information for disambiguating the two messages:
{
"txn_type"=>"subscr_signup",
"subscr_id"=>"unique_id",
"verify_sign"=>"random_gibberish",
"item_number"=>"your_subscription_name"
"subscr_date"=>"14:32:23 Feb 15, 2010 PST",
"btn_id"=>"1111111",
"item_name"=>"Your Subscription Description",
"recurring"=>"1",
"period1"=>"1 M",
# This example is from a "free trial" IPN notification-- if you don't have a
# free trial defined, there will only be 'period1' fields, and they'll
# have the data that appears here in the 'period3' fields.
"amount1"=>"0.00",
"mc_amount1"=>"0.00",
"period3"=>"1 M",
"amount3"=>"34.95",
"mc_amount3"=>"34.95",
"mc_currency"=>"USD",
"payer_status"=>"verified",
"payer_id"=>"payer_unique_id",
"first_name"=>"Test",
"last_name"=>"User",
"payer_email"=>"test_xxxx#example.com",
"residence_country"=>"US",
"business"=>"seller_xxxxxxx#example.com",
"receiver_email"=>"seller_xxxxxxx#example.com",
"reattempt"=>"1",
"charset"=>"windows-1252","notify_version"=>"2.9","test_ipn"=>"1",
}
The second message is the more interesting one in this case. It will essentially be the exact same message you'll get later when the recurring payment is applied. It looks something like this:
{
"txn_type"=>"subscr_payment",
"subscr_id"=>"unique_id",
"verify_sign"=>"random_gibberish",
"txn_id"=>"payment_unique_id",
"payment_status"=>"Completed",
"payment_date"=>"12:45:33 Feb 16, 2010 PST",
"item_number"=>"your_subscription_name"
"subscr_date"=>"14:32:23 Feb 15, 2010 PST",
"custom"=>"data-you-sent-in-a-custom-field",
"id"=>"1",
"payment_gross"=>"34.95",
"mc_currency"=>"USD",
"payment_type"=>"instant",
"payment_fee"=>"1.31",
"payer_status"=>"verified",
"mc_fee"=>"1.31",
"mc_gross"=>"34.95",
"btn_id"=>"1111111",
"payer_id"=>"payer_unique_id",
"first_name"=>"Test",
"last_name"=>"User",
"payer_email"=>"test_xxxx#example.com",
"residence_country"=>"US",
"receiver_id"=>"your_merchant_id",
"business"=>"seller_xxxxxxx#example.com",
"receiver_email"=>"seller_xxxxxxx#example.com",
"protection_eligibility"=>"Ineligible",
"transaction_subject"=>"",
"charset"=>"windows-1252","notify_version"=>"2.9","test_ipn"=>"1",
}
So you can do almost all of your testing without waiting a day. By the time you think you've got it nailed down, you'll be receiving lots of subscription IPN messages the next day.
In addition, here is a link to PayPal's documentation for further reference.
It's possible to resend test IPNs, so you should only need to 'buy' one subscription for testing.
Once you've bought one subscription, here's what to do:
Log into your PayPal sandbox seller account.
Select 'Profile' => 'My Selling Preferences'.
Select 'Instant Payment Notification Preferences' from the third column.
Confirm that IPN is enabled and that the URL is correct.
Click the link to the IPN History page.
Scroll down, tick one or more IPNs and click 'Resend'.
After you confirm, the selected IPN(s) will now be resent to the URL you have specified. You can repeat an unlimited number of times with the same IPN(s).
The excellent answer by #dondo covers the rest.
It used to be that the period specified in days would be treated by the test server as minutes so you'd be called every 3 minutes when specified 'd3'. I think they removed this and I'm not aware of any replacement feature to test subscriptions.
Hey I just wanted to throw a shout out to Neil because that is exactly what I was looking for and I don't have enough reputation to reply or upvote..
Believe it or not paypal still doesn't make it easy to do subscription testing with ipn files :/
So, just because I didn't see it on here and the OP kind of sounded like they were under the impression to only expect two possible responses from papal --
if anyone else is having issues, here are some other txn_type that hit my ipn while doing testing:
//when paypal subscription profile is created for the subscriber
subscr_signup
//payment made for a given billing cycle
subscr_payment
//when subscription fails
subscr_failed
//user cancels subscription - not
subscr_cancel
//end of term - paypal is "done" with that subscriber
subscr_eot
//why I was looking for this thread to begin with lol
recurring_payment_suspended_due_to_max_failed_payment
that last one hit my ipn this morning against every last one of my test subscribers. when I was looking up what that meant, I found that the following are also possible to get:
recurring_payment_profile_created
recurring_payment_profile_cancel
recurring_payment_profile_modify
recurring_payment
recurring_payment_skipped
recurring_payment_failed
I don't know what I did to get that because subscriptions and recurring payments are technically different in PayPal's eyes (subscriptions can possibly never terminate but recurring payments have a cap on the total payments someone can make for any "subscription") but their documentation isn't always straight forward, either, so I dunno. That I'm still working on figuring out as this was a subscription button generated by a sandbox merchant account but whatever.
Happy headaches :)
UPDATE:
I figured out my problem just now - so just so it sounds like I know what I'm doing I'll explain...
I think paypal's subscription sandbox environment is slowly dying. I noticed the other day when I'm messing around in sandbox.paypal.com that I get "Fatal Failure" a lot of times. Refreshing the page seems to correct this most times, although sometimes i have to refresh a few times for the screen to come back.
I am getting the same response from them hitting my IPN file, which explains why every subscription I had got suspended today. Thanks to Neil I was able to resend the IPN response and I captured it into a text file (lol) and then I hit the ipn file reading in the response and throw it back at paypal (its really more complicated than that I'm just making it sound easy).
In any case by refreshing the page I can initiate the paypal handshake more or less on demand and when I do, it's 50/50 - sometimes I get VERIFIED, and sometimes I get Fatal Failure - just like when I try to do much of anything in their sandbox site (Fatal Failure).
Below is an example of part of a failed response I get from them... I get a 200 so I believe hitting their server isn't the issue with connectivity, but I am starting to see a pattern with "Fatal Failure" here and this points to more their end than mine
HTTP/1.1 200 OK
Date: Tue, 29 Sep 2015 02:41:00 GMT
Server: Apache
Fatal Failure
you can also manually create IPN from their sandbox:
https://developer.paypal.com/cgi-bin/devscr?cmd=_ipn-link-session