Double charging

[WiCKeDxgg]

I reached out to my payment processor because a certain customer of mine was double charged twice in a row. Stripe is telling me that invision community is sending 2 webhooks for his payment creating 2 different transactions on there end. How do I resolve this?

[Randy Calvert]

Do you have multiple versions of IPB that exists?  For example, did you copy your IPB to a QA/test instance?

[Marc Stridgen]

8 hours ago, Randy Calvert said:

Do you have multiple versions of IPB that exists?  For example, did you copy your IPB to a QA/test instance?

This is actually the most common cause of this kind of issue, but I noted you selected a cloud item. Have you a copy of that elsewhere?

[Meddysong]

This has happened to me in the past, when backing up my site to a test installation prior to running an upgrade. Because I'd created a perfect replica of the main site, it too was taking repayments. It's a massive oversight, in my opinion, that if the site is at a test location, then these features aren't automatically disabled.

You'll need to add the following to contants.php in your test location:

define( 'NEXUS_TEST_GATEWAYS', TRUE );
define( 'EMAIL_DEBUG_PATH', "/dev/null");

And if you're using Stripe as your gateway, that's still not enough because these changes don't work with it.

The only approach that works for me is to disable Commerce in my live site, make the backup, switch Commerce back on, and then use the backup in the test installation. That way Commerce isn't operational on my test site and so repayments won't be taken.

[Marc Stridgen]

25 minutes ago, Meddysong said:

It's a massive oversight, in my opinion, that if the site is at a test location, then these features aren't automatically disabled.

Im not sure I understand the reasoning there. If they are disabled, there would be no way in which to test them. While I understand you may want to disable them every time, there are many times where user dont

[Meddysong]

56 minutes ago, Marc Stridgen said:

Im not sure I understand the reasoning there. If they are disabled, there would be no way in which to test them. While I understand you may want to disable them every time, there are many times where user dont

You don't understand why an administrator would want to have an app disabled in a test environment which, if activated, will take duplicate payments?

Let's put it another way. Why would any admin want his testing site to be taking the same payments that his main site is? Why would any user want to be charged twice for the same subscription?

I think the ideal situation is to have Commerce -- or, at least, the part of it which takes money -- deactivated in a test environment. Have some sort of notice advising of this, perhaps, with an option to re-enable. But what positive can come of allowing it to take renew membership subscriptions anyway? Why should members be charged twice if their renewal period happens to coincide?

[opentype]

Ideally there should be a “staging mode” with settings to turn off payments, emails and things like that. 

[Marc Stridgen]

21 minutes ago, Meddysong said:

You don't understand why an administrator would want to have an app disabled in a test environment which, if activated, will take duplicate payments?

I feel that was misquoted somewhat. What I actually said if I can see why someone wouldn't want to have it disabled. 

22 minutes ago, Meddysong said:

Let's put it another way. Why would any admin want his testing site to be taking the same payments that his main site is? Why would any user want to be charged twice for the same subscription?

There is of course no scenario where that would be needed. However the test site doesnt know there is a live site which has the same items running, and there are indeed situations where you would want a test site running with live links (for testing those live links)

Dont get me wrong, I agree there could maybe be a better way of handling these. I'm just saying automatically disabling may not actually be the answer

[Meddysong]

On 4/4/2023 at 1:29 PM, Marc Stridgen said:

I feel that was misquoted somewhat. What I actually said if I can see why someone wouldn't want to have it disabled. 

I don't know about misquoting you, Marc, but we might be at crossed purposes. I'm not saying permanently disabled with no option to reenable, and it might be that you think this is what I'm angling for, hence our mutual confusion. I'm saying that they should be disabled by default; a knowledgable user could then reenable them if required. That seems far better to me.

[Marc Stridgen]

1 hour ago, Meddysong said:

I don't know about misquoting you, Marc, but we might be at crossed purposes. I'm not saying permanently disabled with no option to reenable, and it might be that you think this is what I'm angling for, hence our mutual confusion. I'm saying that they should be disabled by default; a knowledgable user could then reenable them if required. That seems far better to me.

Feel free to add that as a suggestion if its something you would like to see in the future

[TDBF]

9 hours ago, Marc Stridgen said:

Feel free to add that as a suggestion if its something you would like to see in the future

Marc, I have been asking for you guys to change this for years now, I have suggested that when on a localhost these options should be disabled by default.

Sometimes when you copy a live site over to a localhost environment, you can forget to turn these options off. The last time, this caused me a lot of issues, with a few members accusing me of trying to rip them off because of the double payments.

 

[Chris Anderson]

4 hours ago, TDBF said:

I have suggested that when on a localhost these options should be disabled by default.

Why not do a license check for testinstall.  If running under that license type disable all functionality you wouldn't want running under that kind of environment. 

[Randy Calvert]

9 minutes ago, Chris Anderson said:

Why not do a license check for testinstall.  If running under that license type disable all functionality you wouldn't want running under that kind of environment. 

That would be potentially great if people actually updated their license when they clone a prod instance to a QA. (You can simply ignore license warnings once installed.)  But if they could fix their license, they could also simply turn off the cron job as easily or had a constants.php created that is non editable or replaceable with those flags set. 

Another idea is within the payment gateway, only accept transactions submitted by your prod instance.   For example in Stripe, create a radar rule to reject transactions that don’t come from your prod server IP. 

Edited May 4, 2023 by Randy Calvert