Jump to content

Vox

Member
  • Posts

    247
  • Joined

  • Last visited

  • Days Won

    3

Vox last won the day on November 1 2023

Vox had the most liked content!

2 Followers

About Vox

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Vox's Achievements

Senior Member

Senior Member (3/3)

16

Reputation

  1. Hi Guys, Updating this thread as WHMCS have confirmed the above post regarding the change of IP address. If the clients IP address changes during the payment process it will not complete. This means that any customers using services such as "iCloud Private Relay" may be prone to payment failures.
  2. Hi @WHMCS John, Ticket ID: YWJ-692022 I've posted screenshots of the Stripe payments dashboard activity along with the web logs for that period. You can see where the payment was attempted twice, but only seems to have the POST and GET entires for the stripe module once. I did notice that the attempts were from two different IP's for the client - I hope that something like "iCloud Private Relay" is not interfering with the process. That's the only reason I can think of as to why the client's IP would change.
  3. Hi @niels, Thanks, I didn't know about that. Nothing there thought that shows any failure though, so would agree with you.
  4. Hi @leemahoney3, The only things I can see in the Apache logs that span the period way before and after the transaction attempt are as follows: which do not seem to correlate with anything to do with Stripe?
  5. Hi Guys, I've just implemented the Stripe gateway a few days ago and I am getting this as well. Most customers are going through fine and then one (existing customer) tried to pay an invoice twice, with the Stripe dashboard showing both attempts as: "PaymentIntent status: requires_capture" I only stumbled across that because after implementing a new payment gateway I was checking regularly for any issues. I'm using WHMCS v 8.8.0 and PHP v 8.1.24 with the standard templates for both client area and order forms..... Nothing non-standard here @WHMCS John. The really annoying aspect of this is that there is no notification from either Stripe or WHMCS that a payment process has been attempted and either failed or requires manual intervention. In fact there is nothing recorded in the WHMCS Gateway Transaction Logs to identify the point of failure............. That is shocking! Once you do capture the payment in Stripe, it is then a case of manually adding a payment to the invoice - great billing system!
  6. @sol2010 Once they have requested cancellation and chosen "End of the billing cycle" the product will not be invoiced when due. https://docs.whmcs.com/Cancellation_Requests However, it will be terminated if you have set a termination date or enabled the function in your "Automation Settings". https://docs.whmcs.com/Automation_Settings#Enable_Termination These settings will allow you to amend both the suspension and termination functions as you require.
  7. @dorianPSLLC It's in Automation Settings: https://docs.whmcs.com/Automation_Settings#Suspend_Days
  8. Hi Guys, A warning regarding the automated process for deleting inactive clients following a ticket I raised...... Firstly, the fourth criteria here https://docs.whmcs.com/Data_Retention_Policy_Automation is completely "reversed". An affiliate with a credit balance will NOT be deleted. However, what is more relevant (well, it occurred to me at least) is that any client who is not an affiliate but has a "genuine" credit balance on their account WILL be deleted, as this falls outside of the 4 criteria being checked. I have been asked (and duly complied 🙄) to submit a feature request: https://requests.whmcs.com/idea/include-credit-balance-check-before-deleting-inactive-clients I just thought that I should share this in case someone gets caught out.
  9. Hi @WHMCS John, The documentation in that link needs to be corrected then. As it specifically refers to that condition meeting the criteria for deletion:
  10. Hi @james322232, Using your example of an order placed on 1st but the payment not clearing until 5th you can just change the "Next Due Date" in the Client Profile > Products/Services from 01/01/2021 to 05/01/2021 (or quarterly or annually whatever). That way the items will be billed on the correct date next time round. As for the initial invoice, you could always go into the invoice and change the service dates to match and then send an "Invoice Modified" email.
  11. Hi @MakarSima182, As I said in the reply to the DM that you sent me, please ask any questions on these Forums. That way it will help everyone, as you can virtually guarantee that another user will have the same question at some time and would benefit from the proposed suggestions or solutions. From my understanding, what you wanted was the customer to setup a Direct Debit, but wanted to provision their services without waiting the seven days or so for the payment to be received. @WHMCS John covered this earlier in this topic by suggesting that you could accept the order manually. It really comes down to how you much risk you are prepared to take in provisioning services before you have received payment.
  12. Hi @james322232, That screenshot looks like there is an error accessing the URL for SagePay Forms. Is the module configured correctly with your SagePay details? I do not use that gateway so maybe someone else can advise you, or alternatively contact SagePay support for assistance.
  13. Hi @james322232, There is a hook here to remove the GoCardless option from the checkout. Beware though, some customers still change the payment method when they get to pay the invoice.
  14. Hi @asil, Have you applied the hot fixes for v8.0.4? If not try this one:
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated