Testplan for Token Payment Processor

Hi everyone, here is our test plan for our Token Payment Processor!
(docs/testplan: Adding a testplan for Token Payment Processor by nadimhq · Pull Request #4672 · storj/storj · GitHub)

We wanted to avoid high gas fees, delays, and in general wanted to make STORJ token payment more feasible as an option!

Test Scenario Test Case Description Comments
Transaction Block Chain Reorg If there is a naturally occurring chain reorg then past transactions in the old chain are deactivated due to a chain reorganization (status – pending to cancelled) Must have early on (Alpha)
Minimum Confirmation A transaction should not be called paid unless it meets the minimum number of confirmations reached (this should be visible in UI, pending until it meets minimum number of confirmations) Must have early on (Alpha)
Two Transactions If there is a pending transaction with less than the number of required confirmations and then there is a reorg and said transaction gets overridden with a longer chain, the old pending transaction should then get removed Must have early on (Alpha)
Stale Pending Transactions Pending transactions that have less than the number of required confirmations and have been stale for a set time should be deleted from the Satellite DB and not stored again Must have early on (Alpha)
Pending Transactions Same as above case, except it will be again stored in DB since all pending transactions are wiped from the DB regardless if they are stale or not (in this case its not stale, just pending and waiting for the minimum # of confirmations) Must have early on (Alpha)
Required Block Confirmations Transactions should have their required blocks for confirmation high enough so that even if there is a reorg with a pending transaction that contains f.e two chains same length in parallel, there shouldn’t be an issue Must have early on (Alpha)
Alerts Resynced Geth Node Geth nodes should be able to sync with the network, if a geth node resyncs it can take several days and so the token payment processor should pick up transactions during this resync. Must have early on (Beta)
UI Block Explorer Link We should be able to view transaction link and number of confirmations given a link to block explorer Must have early on (Alpha)
Transaction Detail If user makes a transaction user should be able to see Ethereum scaling solution used for said transaction (view details) Needed later when we implement zkSync
Testing Recreate Transactions Using sender, receiver, nonce, and transaction fees we should be able to recreate transactions to see if there are any mempool bugs and this should also be doable using storj-up Must have early on for testing
Integrating Storj-scan into Storj-up For ease of testing it would be valuable to have storj-scan built into storj-up (may need integration with satellite for us to test) Can be implemented later
Storj-scan with testnet As stated above, token payment processor has to work with testnet to be able to run in storj-up and use existing testnet geth node Can be implemented
Timestamp Issue It should not be possible for two transactions on a block to share the same timestamp, however If there are two deposits with the same amount to the same address in the same block, then it would mean that they have the same timestamp and the only difference would be the transaction hash because of the different nonce (this is an issue with our current design) Current Design, design will be changed so timestamp will not be relied on
Rescan Rescan should always start from the last fully confirmed block f.e in a reorg, so rescan should start at the height of said block
Invoice Generation When an invoice is generated and paid, coupons should be used first, followed by STORJ balance and then lastly credit card This invoice should be shown to our accounting team and they should be asked if said invoice looks correct

If there is no option to change the order, then as customer I would hate it.
If you have ever used an Amazon coupon, there you find the ideal way to handle payments with different payment types. As a customer I can select which way to pay and choose between using the coupon, parts of it or use a credit card upon checkout. And this is how I would expect it.

Storj monthly bills aren’t an Amazon order. The order listed is 100% correct, in line with best practice and similar to using something like a Paypal account.

Why would you not use a free coupon first when it regenerates every month and the invoice is monthly?
Then you would use the equivalent of prepaid credit (STORJ balance) like a Paypal balance already in your account.
Followed by paying the invoice balance with an external form of payment (credit card).

This also keeps costs lower so card fees are only paid as the final step.