Add payments for dispensing NFTs (separate instruction for SOL and SPL tokens, reason explained below)
Add tests for payments, including test that mints multiple NFTs
Small refactor of utility test methods
Important Design Decision -- Multiple Dispense Instructions for Native SOL vs SPL Token
Originally, there was a single dispense function that was to handle projects that wanted to be paid out in SPL Tokens or in native SOL. The issue with this approach, is that it required the client to pass dummy arguments to the instruction, to satisfy the requirements of the accounts context. I.e. there would need to be two TokenAccounts in the instruction context, if the user was making a purchase in native sol, they would need to supply two junk TokenAccounts for the instruction to go through. This seemed confusing, and not ideal. Instead, we've implemented two instructions, one for purchases in native sol and another for purchases in SPL token. The downside here is that the client needs to know which instruction to use, depending on the project's GumballMachineHeader. However, they effectively already had to know this in order to pull the correct payment accounts, anyways. And with this approach we do not need any wasted accounts in the instruction context.
Changes:
Important Design Decision -- Multiple Dispense Instructions for Native SOL vs SPL Token
Originally, there was a single dispense function that was to handle projects that wanted to be paid out in SPL Tokens or in native SOL. The issue with this approach, is that it required the client to pass dummy arguments to the instruction, to satisfy the requirements of the accounts context. I.e. there would need to be two TokenAccounts in the instruction context, if the user was making a purchase in native sol, they would need to supply two junk TokenAccounts for the instruction to go through. This seemed confusing, and not ideal. Instead, we've implemented two instructions, one for purchases in native sol and another for purchases in SPL token. The downside here is that the client needs to know which instruction to use, depending on the project's
GumballMachineHeader. However, they effectively already had to know this in order to pull the correct payment accounts, anyways. And with this approach we do not need any wasted accounts in the instruction context.