Paypal Ipn Issue - Blesta 3.2.0

[xxxxx]

Hi,

 

I've been having issues trying to get PayPal IPN talk back to Blesta 3.2.0 to actually apply payments to a client's account. Please see the below screenshot. As far as I can see, the Callback URL, etc, are set correctly. I thought this may also be an issue with CloudFlare blocking the IPN callback, but I've added the relevant rules (as far as I can see) to prevent this. I did have this issue with Blesta 2.5 too, but that was a while back and I'm not sure this is related.

 

Any tips or support would be appreciated.

 

Thank you.

 

[Michael]

I think it is Cloudflare, check the logs on Blesta 3.x please.

 

Tools > Logs > Gateways and show input and output here please remove any sensitive information.

Also check if the payment was applied in Blesta for us please.

[xxxxx]

Please see attachment. Thanks. The payment was not applied to the client account.

[Michael]

Please see attachment. Thanks.

 

Weird do you have teamviewer so I can come and see what you see on both paypal and Blesta and see how it's set up so I can see if I can help you. If yes please open two tabs first one with your My profile on PayPal and your settings page.

[xxxxx]

I appreciate your help, but unfortunately I can't allow Teamviewer on this network. If there is anything which would help diagnose the issue I'd be happy to provide it.

[Michael]

Ok mate that's fine look at my pictures and ensure they are exact, maybe turn off cloudflare if they do look the same.

 

PS: you don't need https:// http:// will work fine. PS: you don't need a Page Layout either.

 

 

 

The best way to check is go to your IPN url it should show this even though nothing is going though: /customers/pay/received/

 

Thank You!

Your payment is being processed.

[xxxxx]

Thanks mate. Below is what I have, looks fine to me. The funny thing is, after payment, the browser redirection to the Blesta "Your payment is being processed" page is fine. My other settings, as per your second screenshot are pretty much identical.

 

Notification URL http://accounts.hosthallam.com/callback/gw/1/paypal_payments_standard/

Message delivery Enabled

 

Maybe unrelated: I just had a worrying issue, where using a test account, I went through the order process and it provisioned an Enom domain before any payment attempt :/

[Michael]

Thanks mate. Below is what I have, looks fine to me. The funny thing is, after payment, the browser redirection to the Blesta "Your payment is being processed" page is fine. My other settings, as per your second screenshot are pretty much identical.

 

Notification URL http://accounts.hosthallam.com/callback/gw/1/paypal_payments_standard/

Message delivery Enabled

 

Try removing the 1.

 

NOT This:

http://accounts.hosthallam.com/callback/gw/1/paypal_payments_standard/

But this:

http://accounts.hosthallam.com/callback/gw/paypal_payments_standard/

See if that fixes it for you mate.

[xxxxx]

Thanks mate, have done, I'll just wait for PayPal to retry IPN so fingers crossed. I appreciate your efforts and I will reply ASAP.

[Michael]

Thanks mate, have done, I'll just wait for PayPal to retry IPN so fingers crossed. I appreciate your efforts and I will reply ASAP.

 

You're welcome, if that doesn't work disable cloudflare to see if that solves it.

[xxxxx]

Urgh ...

 

So I changed it, and it doesn't seem to take any effect. Even having Disabled and Re-enabled IPN.

[xxxxx]

Also, regarding the Gateway logs, this is taken from the PayPal API site:

https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNIntro/

 

The numbers in the diagram correspond to the following actions:

1. A user clicks a PayPal button to kick off a checkout flow; your web application makes an API call; your back-office system makes an API call; or PayPal observes an event.
2. PayPal HTTP POSTs your listener an IPN message that notifies you of this event.
3. Your listener returns an empty HTTP 200 response.
4. Your listener HTTP POSTs the complete, unaltered message back to PayPal.

   Note This message must contain the same fields, in the same order, as the original IPN from PayPal, all preceded by cmd=_notify-validate. Further, this message must use the same encoding as the original.

5. PayPal sends a single word back - either VERIFIED (if the message matches the original) or INVALID (if the message does not match the original).

Remember To prevent fraud, your IPN listener must implement the IPN authentication protocol (steps 2, 3, 4, and 5 in the diagram above). Upon receipt of a VERIFIED response, your back-office process can parse the contents of the IPN message and respond appropriately - print a packing list, enable a digital download, etc.

[Michael]

Try removing Cloudflare see if it is that causing it, because I've not seen this issue before :s

 

PS: is your order page url supposed to link to nothing or have you set a default order form?

[xxxxx]

Just disabled CloudFlare for the 'accounts.' subdomain. I've been playing with the order forms, but I've set the default now, thanks.

[xxxxx]

And...it looks like it was CloudFlare as suspected. I imagine it messed with the IPN response and caused it to malform, throwing an "INVALID" response. The IPNs just shot through using the link with the "/1/".

 

http://accounts.hosthallam.com/callback/gw/1/paypal_payments_standard/

 

Now, I'm still worried about the issue where an Enom domain was registered without me even attempting to make a payment, any idea?

[Michael]

And...it looks like it was CloudFlare as suspected. I imagine it messed with the IPN response and caused it to malform, throwing an "INVALID" response. The IPNs just shot through using the link with the "/1/".

 

http://accounts.hosthallam.com/callback/gw/1/paypal_payments_standard/

 

Now, I'm still worried about the issue where an Enom domain was registered without me even attempting to make a payment, any idea?

 

If you have credit on your Enom account, and a domain has been paid for it should process it automatically (Or process and be in pending payment on Enom), if you want to stop that you can manually approve orders.

 

Packages > Order form > Edit > Tick: Require Manual Review and Approval of All Orders

 

That should make you manually approve them beforehand. So you can add credit then activate the order.

[xxxxx]

Thanks, but the thing is, there was no credit on the test client's Blesta account. It was a new test account which had no credit whatsoever. I signed in as that user, went through the order process and stopped on final page, with the PayPal button, and never went any further. A minute or so later, I got an email from Enom notifying me of the new registration. Very worrying.

 

I would hope that expected behaviour is not to interact with the Enom module at all until the Blesta account has appropriate credit.

 

Just to make it clear, the issue isn't with Enom credit, I keep it topped up, it's with Blesta not taking client payment before purchasing the domain via API.

[Michael]

Thanks, but the thing is, there was no credit on the test client's Blesta account. It was a new test account which had no credit whatsoever. I signed in as that user, went through the order process and stopped on final page, with the PayPal button, and never went any further. A minute or so later, I got an email from Enom notifying me of the new registration. Very worrying.

 

I would hope that expected behaviour is not to interact with the Enom module at all until the Blesta account has appropriate credit.

 

Just to make it clear, the issue isn't with Enom credit, I keep it topped up, it's with Blesta not taking client payment before purchasing the domain via API.

 

Oh yeah that's normal, you mean they register the client on your enom account not they register the domain, that happens on ever reseller module for most billing systems. The old one I used did the same.

[xxxxx]

Not sure we're talking about the same thing haha. Let me clear this up.

 

1) I created a Blesta test client (£0.00 credit on that account)

2) I logged in to Blesta as that test client.

3) I used my Order form to order domain and hosting but ABORTED BEFORE making payment. E.g. Got to the "Pay with PayPal" graphic and simply closed the window.

4) Received an Enom email, confirming registration of the domain which SHOULD NOT have been registered as the test client DID NOT pay for it.

 

I hope that makes it clearer. Essentially, as a host, I'm out of pocket as a domain was registered by Blesta, via the Enom API, without confirming that the Blesta client had paid or had the appropriate credit on his account.

[Michael]

Not sure we're talking about the same thing haha. Let me clear this up.

 

1) I created a Blesta test client (£0.00 credit on that account)

2) I logged in to Blesta as that test client.

3) I used my Order form to order domain and hosting but ABORTED BEFORE making payment. E.g. Got to the "Pay with PayPal" graphic and simply closed the window.

4) Received an Enom email, confirming registration of the domain which SHOULD NOT have been registered as the test client DID NOT pay for it.

 

I hope that makes it clearer. Essentially, as a host, I'm out of pocket as a domain was registered by Blesta, via the Enom API, without confirming that the Blesta client had paid or had the appropriate credit on his account.

 

Ok not sure the guys will be best to help you as I've only used LogicBoxes resellers, which automatically register an account on the reseller for the customer and after payment puts the domain pending unless there's account credit. 

Why is Enom registering domains if you have no money on it? It personally sounds like a Enom issue but I'm not 100% sure.

[xxxxx]

Ok not sure the guys will be best to help you as I've only used LogicBoxes resellers, which automatically register an account on the reseller for the customer and after payment puts the domain pending unless there's account credit. 

Why is Enom registering domains if you have no money on it? It personally sounds like a Enom issue but I'm not 100% sure.

 

Thanks pal. Not sure we're on the same page. As I said, I keep my Enom account topped up. I'm not reselling Enom accounts, I'm selling Domain Names only. Basic issue, it's registering domains before a Blesta client has paid for it.

[Tyson]

1) I created a Blesta test client (£0.00 credit on that account)

2) I logged in to Blesta as that test client.

3) I used my Order form to order domain and hosting but ABORTED BEFORE making payment. E.g. Got to the "Pay with PayPal" graphic and simply closed the window.

4) Received an Enom email, confirming registration of the domain which SHOULD NOT have been registered as the test client DID NOT pay for it.

 

No service should be created until its associated invoice has been paid. I know you said it wasn't paid and there was no credit, but it would have created the service if the cron found enough credit to mark the invoice paid, or you manually created the service from the admin area. If you can re-confirm (and post steps to duplicate) that would be helpful in determining whether it's a bug.

[xxxxx]

No service should be created until its associated invoice has been paid. I know you said it wasn't paid and there was no credit, but it would have created the service if the cron found enough credit to mark the invoice paid, or you manually created the service from the admin area. If you can re-confirm (and post steps to duplicate) that would be helpful in determining whether it's a bug.

 

Thanks Tyson. I'll try to re-create the issue as soon as possible. I'm certain the the account in question did not have any credit.