How should production credit card details be handled in Uilicious tests?
All payment providers, including stripe. Strongly recommends the usage of test credit cards in testing environment. You can find details for stripe here - and this is for good reason.
Even if Uilicious platform, and team is perfectly secure, from external threats. You will have to consider the security of everyone on your team who has access to the reports. Credit cards are typically not masked from screenshots, and as such, would be clearly visible to all members who has access to your Uilicious project. As such, from a security stand point, you should consider this information potentially compromised, and treat it as such.
However we understand, that for some teams, perhaps their no-code platform, or vendor do not provide a test environment. Or perhaps some payment issues can only be found in production environment.
In that case - despite the above warnings, if you have to proceed with using a real credit card : i would recommend the following precautions. And work with a security model, where you presume the card will be compromised at some point, and can react quickly when it happens.
Use the uilicious dataset to store it as a secret, this would at the least remove it from the text outputs (but not the screenshots). Making it less visible and reduce the chances of compromise.
Use a dedicated, private credit card for the sole purpose of testing
For the US, consider services like : https://privacy.com/
For all other countries, consider using a wise credit card : https://wise.com/sg/borderless/card (note the owner has no limit, so you need to create 2 accounts)
You could probably get another "free" credit from the bank
Configure a really low credit limit (like $500). Most bank would insure card compromises up to a certain $X00. So if possible try to make sure your limit is under that, to fully protect yourself from losses on compromise.
If your card allows it, you can even configure notification to anything not in a fixed list, or block transaction outside a list.
Despite all the above, most banks will treat multiple repeated transaction as a "red flag" or "fraud risk" and block the transaction. And you will need to do the following additional measures to prevent it.
A 100% discount code should work most of the time, however as a fraud prevention measure, most payment provider may still do a $1 transaction followed by a refund. This reduces the rate of which your transaction will be blocked, but not eliminate it.
Try to limit the test once a week per card first, for a month. Before scaling it up slowly to once a day (depending on your test needs). Be prepared to resolve blocked payments with the bank as you scale up to once per day.
Generally more than once per day will be blocked. Rotate multiple cards if your testing needs is more than once per day.
Note that if you high number of "suspicious" transaction, you may incur chargebacks from your bank/payment provider. This is basically their way of billing you for investigating these issues.
Consider doing a balanced approach to testing the above. And split your credit card tests into two separate sets
One set, where the test will do all the steps, up to and before checkout. Switch over to a dashboard/admin account, to create the transaction with in store credits / manual payment option / without a card. Allowing the test to continue the steps "after the checkout". This is executed frequently or daily.
Another set of tests, which uses the actual credit card, executed weekly, or on scheduled deployment.
If all the above is applied, you can limit your potential losses up to the spending limit and the chargeback fees from the payment providers, when done correctly. Allowing you to test using actual credit cards "relatively safely"
Legal Disclaimer:
Uilicious do not insure, nor take responsibility for the credit card data provided in test scripts, and test datasets.
For uilicious.com cloud payments, this is handled securely by stripe.com.
The above information is provided, as it is. Do so at your own risk.
Even if Uilicious platform, and team is perfectly secure, from external threats. You will have to consider the security of everyone on your team who has access to the reports. Credit cards are typically not masked from screenshots, and as such, would be clearly visible to all members who has access to your Uilicious project. As such, from a security stand point, you should consider this information potentially compromised, and treat it as such.
However we understand, that for some teams, perhaps their no-code platform, or vendor do not provide a test environment. Or perhaps some payment issues can only be found in production environment.
In that case - despite the above warnings, if you have to proceed with using a real credit card : i would recommend the following precautions. And work with a security model, where you presume the card will be compromised at some point, and can react quickly when it happens.
Use the uilicious dataset to store it as a secret, this would at the least remove it from the text outputs (but not the screenshots). Making it less visible and reduce the chances of compromise.
Use a dedicated, private credit card for the sole purpose of testing
For the US, consider services like : https://privacy.com/
For all other countries, consider using a wise credit card : https://wise.com/sg/borderless/card (note the owner has no limit, so you need to create 2 accounts)
You could probably get another "free" credit from the bank
Configure a really low credit limit (like $500). Most bank would insure card compromises up to a certain $X00. So if possible try to make sure your limit is under that, to fully protect yourself from losses on compromise.
If your card allows it, you can even configure notification to anything not in a fixed list, or block transaction outside a list.
Despite all the above, most banks will treat multiple repeated transaction as a "red flag" or "fraud risk" and block the transaction. And you will need to do the following additional measures to prevent it.
A 100% discount code should work most of the time, however as a fraud prevention measure, most payment provider may still do a $1 transaction followed by a refund. This reduces the rate of which your transaction will be blocked, but not eliminate it.
Try to limit the test once a week per card first, for a month. Before scaling it up slowly to once a day (depending on your test needs). Be prepared to resolve blocked payments with the bank as you scale up to once per day.
Generally more than once per day will be blocked. Rotate multiple cards if your testing needs is more than once per day.
Note that if you high number of "suspicious" transaction, you may incur chargebacks from your bank/payment provider. This is basically their way of billing you for investigating these issues.
Consider doing a balanced approach to testing the above. And split your credit card tests into two separate sets
One set, where the test will do all the steps, up to and before checkout. Switch over to a dashboard/admin account, to create the transaction with in store credits / manual payment option / without a card. Allowing the test to continue the steps "after the checkout". This is executed frequently or daily.
Another set of tests, which uses the actual credit card, executed weekly, or on scheduled deployment.
If all the above is applied, you can limit your potential losses up to the spending limit and the chargeback fees from the payment providers, when done correctly. Allowing you to test using actual credit cards "relatively safely"
Legal Disclaimer:
Uilicious do not insure, nor take responsibility for the credit card data provided in test scripts, and test datasets.
For uilicious.com cloud payments, this is handled securely by stripe.com.
The above information is provided, as it is. Do so at your own risk.
Updated on: 19/09/2023
Thank you!