Invoice "pay Now" Timing Out?

[Qurius]

Hello -

I'm trying to narrow down a problem with customers having trouble using the "Pay Now" function in invoices. It works fine if they open the invoice and click on the "Pay Now" and complete the process but I've had several instances where a customer opens an invoice but does not complete the payment process or just closes the invoice and tries to pay it later and at that point it no longer works so I end up having to resend the invoice.

 

Is there a token on the "Pay Now" that once clicked on is no longer valid?

 

Thanks for the help

[Michael]

It might be a web browser issue? What browser are they using? I've not heard of anyone else having that issue at the moment, what happens if they click Make a payment and enter the amount and click continue?

[Tyson]

There's no limit to making a payment for an invoice except when the invoice is already paid.

 

What process of making a payment is not working correctly, exactly? Is this related to the link sent in an email, or a link in the dashboard, or..?

[Qurius]

It might be a web browser issue? What browser are they using? I've not heard of anyone else having that issue at the moment, what happens if they click Make a payment and enter the amount and click continue?

 

There's no limit to making a payment for an invoice except when the invoice is already paid.

 

What process of making a payment is not working correctly, exactly? Is this related to the link sent in an email, or a link in the dashboard, or..?

 

 

Trying to work with a client to troubleshoot an issue like this can be a challenge so I'm trying to replicate it with some test invoices but from what I hear back the error happens as soon as they click on the "Pay Now"  link in the email  so they don't get to the dashboard.

 

I'll update if I get more information

 

Thanks

[Paul]

Trying to work with a client to troubleshoot an issue like this can be a challenge so I'm trying to replicate it with some test invoices but from what I hear back the error happens as soon as they click on the "Pay Now"  link in the email  so they don't get to the dashboard.

 

I'll update if I get more information

 

Thanks

 

Are the links correct? Do they contain http:// or https:// as the protocol? Does your website redirect http requests to https? If so, that may break the links.

[Qurius]

Are the links correct? Do they contain http:// or https:// as the protocol? Does your website redirect http requests to https? If so, that may break the links.

 

The links are good with no redirects...and most don't have a problem when paying off the email. Also the one's that have had problems when I resend the invoice it works fine. It's not a lot but enough to want to try and figure out what might be causing it.

[Paul]

The links are good with no redirects...and most don't have a problem when paying off the email. Also the one's that have had problems when I resend the invoice it works fine. It's not a lot but enough to want to try and figure out what might be causing it.

 

That's definitely unusual. Are the links different between the time the user had trouble and the time it was resent? You can check the mail log for the specific client to compare. Client Profile > Actions > Mail Log.

[Qurius]

Ok I think I've narrowed it down. I confirmed that it its failing with a 404 error if using the Pay Now link off the 1st notice email. The "pay now" url is different between the first email (unpaid) and the 2nd (1st notice)...

 

Here are the differences:

 

Unpaid template ->      Pay Now, visit http://{invoice.payment_url} (No login required)

1st Notice Template->  Pay Now, visit http://{payment_url} (No Login Required)

 

url in mail log for Unpaid email->    domain.com/client/pay/method/37/etc....

url in mail log for 1st notice->         domain.com/clients/client/pay/method/37/etc...

 

Not sure why the "payment_url"  tag produces a different url in the second template but should I assume that by just copying the {invoice.payment_url} tag to the other templates should fix the issue?

[Tyson]

should I assume that by just copying the {invoice.payment_url} tag to the other templates should fix the issue?

No, that wouldn't work.

 

 

Ok I think I've narrowed it down. I confirmed that it its failing with a 404 error if using the Pay Now link off the 1st notice email. The "pay now" url is different between the first email (unpaid) and the 2nd (1st notice)...

 

Here are the differences:

 

Unpaid template ->      Pay Now, visit http://{invoice.payment_url} (No login required)

1st Notice Template->  Pay Now, visit http://{payment_url} (No Login Required)

 

url in mail log for Unpaid email->    domain.com/client/pay/method/37/etc....

url in mail log for 1st notice->         domain.com/clients/client/pay/method/37/etc...

 

The payment URL's are constructed identically. The difference leads me to believe that the issue is with the cron caused by your Root Web Directory setting. See my other post regarding this issue.

[Qurius]

I read your other post and double checked the Root Web Directory setting and it looks correct ( /home/user_account/public_html/ ) . I probably shouldn't be trying to apply logic here but if the cron works for unpaid invoices doesn't it not use the same process when it sends out 1st, 2nd and 3rd notices ? 

 

Sorry if I'm missing something but just trying to understand the process better.

[Tyson]

I read your other post and double checked the Root Web Directory setting and it looks correct ( /home/user_account/public_html/ ) . I probably shouldn't be trying to apply logic here but if the cron works for unpaid invoices doesn't it not use the same process when it sends out 1st, 2nd and 3rd notices ? 

 

Sorry if I'm missing something but just trying to understand the process better.

 

The cron does use the same payment URL for late notices as well as unpaid invoices that it sends, so your issue is strange if the resulting URL differs.

 

The problem with URLs being incorrect usually comes down to two criteria:

1. The Root Web Directory is not set to the correct path. Because of this, URLs in emails sent via cron are incorrect.
2. The email template itself has set the wrong tag/URL. All emails will have an incorrect URL.

You just mentioned your Root Web Directory being set to /home/user/public_html/, which looks correct to me.

 

If you're sure that all of the email templates have the correct URLs set in both the HTML and Text versions of the template, then you'll have to narrow down which templates are affected.

 

I would test the following:

- Find a recent 'Unpaid Invoice' email from the client's mail log that you know was sent to them via cron from the command line (not from you running the cron manually from Blesta). Make a note of the payment URL.

- Find that same invoice on the client's profile page, check the box next to it, and send it to yourself. Then make a note of the payment URL. You will need to look at the Text version of the email in your mail application instead of the HTML version to get an accurate comparison. Are the payment URLs identical between HTML and Text, as well as with the email from the client's mail log?

[Qurius]

The cron does use the same payment URL for late notices as well as unpaid invoices that it sends, so your issue is strange if the resulting URL differs.

1. The email template itself has set the wrong tag/URL. All emails will have an incorrect URL.

 

If you're sure that all of the email templates have the correct URLs set in both the HTML and Text versions of the template, then you'll have to narrow down which templates are affected.

 

 

Sorry I may not have been clear enough in my previous posts. The issue is only related to the late notice templates which do have a bad tag/url :

 

Unpaid template ->      Pay Now, visit http://{invoice.payment_url} (No login required)  These always work

Late Notice Templates ->  Pay Now, visit http://{payment_url} (No Login Required)  These fail with a 404 error

 

You mentioned that I can't copy the tag {invoice.payment_url} from the unpaid template to the late notice template because it won't work so that's where I'm lost.

[Tyson]

I was suggesting testing the invoice templates because they can be sent manually via web as well as automatically via cron in CLI, which can be useful in determining whether there is a difference in the construction of the URL between the two methods, indicating a potential issue with the root web directory setting. Since the invoice templates construct the payment URL identically to the late notices, the same result should be expected for both templates when sent via cron.

 

If you're positive that the payment URLs differ between the late notices and unpaid invoice templates when sent via cron, then there is some other issue causing it that is unexpected, such as custom code changes that reset the configured company's hostname at run-time. But that seems unlikely. In such a case, it may be simpler to programmatically debug the cron to determine where the difference is coming from.

 

You mentioned that the incorrect URL is constructed as domain.com/clients/client/pay/... rather than domain.com/client/pay/... -- is Blesta installed in a /clients/ directory on the server? Is there a subdomain setup for Blesta? Are there rewrite rules defined in an .htaccess file to perform redirects related to Blesta? Is Blesta installed in a virtual directory (does the physical path to Blesta differ from the virtual path the web server uses)?

[Qurius]

"You mentioned that the incorrect URL is constructed as domain.com/clients/client/pay/... rather than domain.com/client/pay/... -- is Blesta installed in a /clients/ directory on the server?

Yes Blesta is installed in the /clients/ directory

 

Is there a subdomain setup for Blesta? 

Yes it is setup as clients.domain.com

 

Are there rewrite rules defined in an .htaccess file to perform redirects related to Blesta?

No rewrite rules that do redirects

 

Is Blesta installed in a virtual directory (does the physical path to Blesta differ from the virtual path the web server uses)?"

No

[Paul]

Not sure this was already asked but did you check both the HTML and Text versions of the email templates? Are they consistent?

[Qurius]

Yes...the late notice templates have the same  {payment_url} link/url in the html and text versions for the "Pay Now"

[Qurius]

Running another set of tests...

 

• Running the cron manually from settings->system->automation produces the correct "Pay Now" link (clients.domain.com/client/pay/method/40/etc) in the unpaid emails

• Running the same cron via cli  produces the wrong url/link in the unpaid emails -> clients.domain.com/clients/client/pay/method/40/etc...

 

• The cron in Settings->System->Automation is ->  /usr/bin/php /home/user/public_html/clients/index.php cron (This matches what is in the cron job in Cpanel)
• The Root Web Directory in System->Settings->General->Basic Setup is ->  /home/user/public_html/
• Blesta is located in the clients directory off the root -> /home/user/public_html/clients/
• Blesta is setup as a subdomain -> clients.domain.com

If anyone sees anything that pops out let me know.

 

Thanks

[Tyson]

It sounds like your web server's document root for your clients subdomain is actually /home/user/public_html/clients/ rather than /home/user/public_html/, so I suspect appending /clients/ to your Root Web Directory setting will resolve the URL issue for emails sent by cron via CLI.

[Qurius]

Ok one step forward and one back   

 

I changed the Root Web Directory to /home/user/public_html/clients/  and sent a test invoice via the cron job CLI and the url for the "Pay Now" is now correct and goes to "/clients.domain.com/client/pay/method/41/etc..."

 

However the url in the email for the "My Dashboard"/{client_url}  now goes to a login only page instead of the client portal of "clients.domain.com" which is how it was before changing the Web Root. Is there anyway to change that?

 

Sorry for this turning into such a pain...

[Tyson]

However the url in the email for the "My Dashboard"/{client_url}  now goes to a login only page instead of the client portal of "clients.domain.com" which is how it was before changing the Web Root. Is there anyway to change that?

 

Sorry for this turning into such a pain...

 

Can you clarify? I'm not sure which email template you're referring to or which URL you are seeing compared to what it should actually be.

[Qurius]

Can you clarify? I'm not sure which email template you're referring to or which URL you are seeing compared to what it should actually be.

 

It's actually my confusion about what it should be doing...before we changed the Root Web Directory, the url's in the unpaid invoice emails for the {client_url}  were going to "clients.domain.com/" which brought up the Client Portal web page where they could login or pay from there. I realize now that changing the Web Root to "/home/user/public_html/clients/ " brings it to the login only page which I assume is correct. While I would prefer the "My Dashboard" link in the emails go to Portal page at "clients.domain.com/" I can live with it the way it is.

 

Thanks again for all your time and help.

[Michael]

It's actually my confusion about what it should be doing...before we changed the Root Web Directory, the url's in the unpaid invoice emails for the {client_url}  were going to "clients.domain.com/" which brought up the Client Portal web page where they could login or pay from there. I realize now that changing the Web Root to "/home/user/public_html/clients/ " brings it to the login only page which I assume is correct. While I would prefer the "My Dashboard" link in the emails go to Portal page at "clients.domain.com/" I can live with it the way it is.

 

Thanks again for all your time and help.

 

 

If you are using a subdomain that folder is the root directory.

[Qurius]

Yes...I see the documentation about the Root Web Directory pertaining to sub-domains was just updated and that helps.

[Tyson]

I realize now that changing the Web Root to "/home/user/public_html/clients/ " brings it to the login only page which I assume is correct. While I would prefer the "My Dashboard" link in the emails go to Portal page at "clients.domain.com/" I can live with it the way it is.

 

The {client_url} tag links to the client dashboard if they are already logged in, or otherwise shows them the login page.

 

If you want to link them to the portal page, you don't want to use the {client_url} or {client_uri} tags, but the {base_uri} tag instead. See the documentation on email tags.