If TESTINSTALL, don't take renewal payments automatically

[Meddysong]

Why on earth does the software send renewal invoices from a backup installation? Isn't that just asking for trouble?

Even if an admin knows to set NEXUS_TEST_GATEWAYS to TRUE in constants.php, they shouldn't really have to, should they?

Even if they do, it doesn't seem to work. Here's the content of my constants.php file:

<?php

define('USE_DEVELOPMENT_BUILDS', TRUE );
define( 'COOKIE_PREFIX', 'eab_' );
define( 'NEXUS_TEST_GATEWAYS', true );
define( 'EMAIL_DEBUG_PATH', "/dev/null");

Here's the date that I created it:

And yet look what's happening in my ACP:

1) What is going on here? Why is my backup site sending renewal invoices when I've expressly set it not to via constants.php?

2) Why should I even have to do that anyway? It's not an obvious thing to do when you're creating a backup for testing purposes or prior to upgrade. If the TESTINSTALL licence key is used, then why isn't this functionality automatically disabled, with perhaps an option to activate it in the ACP?

[Meddysong]

Refining my thinking/complaint, now that I've thought about it. It's not sending out the invoices because otherwise we'd have heard from some of the several people, and we wouldn't have so many people people not having paid. Come to think of it, the gentleman who informed me yesterday didn't mention anything about having received an invoice: he said that a payment had been erroneously taken from his account.

So it seems to be the system is correctly obeying the instruction not to send emails. (define( 'EMAIL_DEBUG_PATH', "/dev/null"); in constants.php.) What's gone wrong seems to be that it's processing the payments for people whose cards are on record.

So I should refine my wording a little bit, having just sent in a ticket about the problem.

Why would a test installation need to take payments or send emails, other than for testing purposes? We're all encouraged to backup our databases prior to upgrade, and to test in advance. That's why we all have the option of a TESTINSTALL licence. Why isn't it the case that if the installation is a test one, sending invoices and taking money isn't disabled by default, with perhaps an option to opt into it for testing purposes, much as one can enter Designers' Mode?

[Nathan Explosion]

Are you using Stripe?

Update: you were in the past...see below:

I expect the same situation exists now.

Edited July 2, 2021 by Nathan Explosion

[Meddysong]

That'll be it, then. When I duplicated the live site, it wouldn't have occurred to me to change the Stripe API keys. One more thing to remember, then. Thanks for the tip-off.

[Chris Anderson]

When using the 'NEXUS_TEST_GATEWAYS' constant TRUE or FALSE, why couldn't the commerce code be modified to switch between communicating with a payment processor or creating an entry in a Test Payment Logs file viewable in the Support Section of the ACP that a transaction was initiated? 

This way you could test the software suite with live data without the risk of double charging any customer.

Edited July 2, 2021 by Chris Anderson

[Stuart Silvester]

44 minutes ago, Chris Anderson said:

When using the 'NEXUS_TEST_GATEWAYS' constant TRUE or FALSE, why couldn't the commerce code be modified to switch between communicating with a payment processor or creating an entry in a Test Payment Logs file viewable in the Support Section of the ACP that a transaction was initiated? 

This way you could test the software suite with live data without the risk of double charging any customer.

There are many legitimate reasons why you would still want the payments to go to the gateway when using test gateways. A big one is that we wouldn't be able to test issues customers reports or work on bug fixes/features with out it, it is extensively used through our development process and by customers who provide development and support to other users of Commerce.

The thing is, the constant will change most gateways to send data to their sandbox/test environments instead of their live environment but Stripe does not work in the same way. Stripe relies on the API Key provided to determine if the data is for a live transaction or a test transaction. If you're using a live API key on your test site then Stripe is going to interpret the data as live data.

TLDR, Generate a test api key and use that on your test site instead.

[Meddysong]

15 minutes ago, Stuart Silvester said:

There are many legitimate reasons why you would still want the payments to go to the gateway when using test gateways.

Fine, but why not allow one to opt into that functionality on a test installation? If you need to do this testing, you're likely to be more familiar with development and the IC platform than generic users such as me are. We, not knowing any better, are the individuals who will think we're being responsible in creating a test environment before upgrading, etc, in total ignorance that we should've made changes to constants.php. (This doesn't solve the particular issue with Stripe, I know.)

(Is a solution simply to remove the payment gateways in the test environment or will Stripe continue to bill anyway?)

[Chris Anderson]

I was totally unaware of the additional available constants that @Meddysongmentioned above as they are not listed in the constants.php Help Guide.

@Stuart SilvesterThere may be value in creating an detailed Help Guide for setting up and utilizing test sites effectively.  Especially considering you rely a great deal on your customers for testing each of your releases, and having fewer support requests benefits everyone.  This could be a collaborative effort between your company and your most knowledgeable customers.

Being an effective tester requires an entirely different mindset and knowledge base than being a community manager.  That is something you have experience with, why not share your knowledge in an easily digestible fashion.  

 

[Marc]

21 minutes ago, Chris Anderson said:

I was totally unaware of the additional available constants that @Meddysongmentioned above as they are not listed in the constants.php Help Guide.

@Stuart SilvesterThere may be value in creating an detailed Help Guide for setting up and utilizing test sites effectively.  Especially considering you rely a great deal on your customers for testing each of your releases, and having fewer support requests benefits everyone.  This could be a collaborative effort between your company and your most knowledgeable customers.

Being an effective tester requires an entirely different mindset and knowledge base than being a community manager.  That is something you have experience with, why not share your knowledge in an easily digestible fashion.  

 

Added to the list for future guides.