Jump to content
  • 0

Invoice "pay Now" Timing Out?


Qurius

Question

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

Link to comment
Share on other sites

23 answers to this question

Recommended Posts

  • 0

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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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?

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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?

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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)?

Link to comment
Share on other sites

  • 0

"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

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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...

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...