|
SOL Transaction
This plug-in provided command either performs a payment at installation time, or validates a past payment that had been performed on the ; enabling validations for reinstallations.
New Transactions
A first time payment involves a transaction between the buyer (your end-user), the seller (you as the developer and publisher), and the service provider (InstallAware).
The service provider earns a commission as part of the transaction ().
Fees charged to record your transaction on the are automatically calculated and passed on to the buyer. The buyer must have sufficient extra funds to cover these fees for the transaction to succeed.
Unlike traditional payment systems, the buyer therefore pays slightly more than the advertised price for each transaction. As of this writing, based on the exchange rate of 143 : 1 SOL, current fee totals approach a flat rate of 27 cents per transaction.
The seller receives all remaining funds, minus the commission.
Querying Past Transactions
A past payment validation queries the whether the buyer had purchased the seller product at any point in the past, cross referenced with the (described below) that had been recorded at the time of the purchase (expected to identify the last used to perform the transaction on).
Rust
All transactions and queries are facilitated with a dedicated , which records all details of your transactions on the .
Gateway: (mainnet or testnet or devnet)
Choose whether transactions are performed with real currency or testing currency.
For real currency, choose mainnet. For testing currency, choose any of the other alternatives. The powering your transactions is available on all three of these nets.
testnet is bleeding edge and may be down more frequently, while devnet is a more stable testing alternative.
As of this writing, you may obtain free testing currency from the located at https://faucet.solana.com/.
Unique Product ID: (GUID recommended)
Type in your unique product identifier in this field. To ensure uniqueness, you may generate a manually, or by clicking the ... button - although manually entering a product name works as well.
The buyer's transaction will be recorded for this product only.
If you do not enter a unique ID in this field or leave it blank, your software could be reinstalled without limit on any number of s where other ill-defined products may have been purchased before.
Unique System ID: (reinstallation allowed on match)
Enter a unique identifier for the the setup is running on.
For new purchases, this value will be recorded in the . For reactivations of past purchases, this value will be compared against purchases by the buyer for the product identifier as specified above in the field. If there is a match, a past purchase was made by the buyer on the same .
To generate this ID, you may use the Generate GUID command, the Generate System ID command, or the Get System Settings command with the parameter.
Using a new for each installation effectively makes it impossible to reactivate the product during reinstallations, and would require a new purchase each time (which may be desirable for certain products).
Using a pseudo-unique machine identifier would not prevent fraudulent reinstallations on additional s that may have been cloned from the buyer's original where the initial purchase had been made.
If you do not enter a unique identifier in this field or leave it blank, your software could be reinstalled without limit on any number of s, after it has been purchased at least once by any one buyer.
Cost: (in Lamports)
Specify a fixed cost directly in the cryptocurrency, as a whole integer, in the smallest unit of called a . No decimal points or thousand separators are allowed.
One unit of makes 1000000000 . The Solana Setup Template contains script code that converts to based on live exchange rates.
Public Key: (seller)
Type in your in this field. This identifies the where the funds would be sent to.
Private Key: (buyer, for making a new purchase)
To make a new purchase, enter the name of the variable that holds the of the buyer in this field.
If specified, this variable must have been previously defined in your setup script using the Set Variable command, where it was assigned to the of the buyer account. The entire field must contain only the name of this variable, without any additional text.
To ensure the privacy of your buyer, this plug-in command will wipe the value of this variable immediately after execution.
As a best practice, your buyer should create a new 'burner' account for this transaction, and fund it with currency just sufficient to cover the transaction (and fees added on top). This ensures a malicious actor cannot then steal the of the buyer for future reuse.
To validate a past purchase, this variable must be blank, or the field may be left entirely empty.
If an identical past purchase was made, the new purchase shall be reported to have succeeded, without actually debiting the buyer account.
If both this field and the field below have been specified, a lookup will be performed as if the had not been specified.
Public Key: (buyer, for looking up a past purchase)
To validate a past purchase, enter the name of the variable that holds the of the buyer in this field.
If specified, this variable must have been previously defined in the setup script using the Set Variable command, where it was assigned to the of the buyer account. The entire field must contain only the name of this variable, without any additional text.
To make a new purchase, this variable must be blank, or the field may be left entirely empty.
If both this field and the field above have been specified, a lookup will be performed as if the had not been specified.
Return result in variable:
Enter the name of the variable to receive the result of the transaction.
Not providing a variable in this field would still debit a buyer account where applicable, while rendering the command practically useless.
If specified, this variable must have been previously defined in the setup script using the Set Variable command.
The variable will hold if the purchase or lookup was successful, and otherwise.
The command will timeout after 60 seconds, in the event that a purchase or lookup was not successfully confirmed by the timeout duration.