I think it'd be best to start with free or low fee until gain many users, once it's proven to be success & useful then begin monetizing it, gradually raising free price/%. But begin at 6% fee with an untrusted, no reputation company seems to high & too risky.
If you think tough men are dangerous, wait until you see what weak men are capable of.
- Jordan B. Peterson
Interesting concept.
Just curious how the work flow would be, so correct me if I'm wrong here:
- Visitor wants to make a payment, gets shown an info message about installing/visiting the Dapp.
- The dapp functions as a wallet with custom features, I assume? The dapp would be just a website and/or browser extension, mobile app etc?
- Visitor deposits x amount of tokens to his new wallet address (through the dapp).
- Visitor clicks button to accept auto payments (signs contract with his private key, basically), which initiates the smart contract for automated monthly payments.
And since you are looking to charge a fee, would that mean there's also going to be some additional services included?
For example, an api endpoint for website owners to verify if the smart contract was executed with success (or not, in case the customer doesn't have enough funds). Or rather use services like infura.io to verify transactions themselves?
Something along those lines? (Not an Ethereum expert, so perhaps you can explain the work flow a bit better)
Select the plan you want and send the ETH/BNB/BUSD/USDT
the contract receives the ETH/BNB or pulls the USDT/BUSD from the customers account
computes a commission
Sends net to Paysite Wallet
Send Fee to Fee Wallet
and here is where I am not 100% sure:
sends a postBack to the website ( not sure if doing in the contract or the app
send email to purchaser ( would have to collect email from user )
so the question is what would be needed on the postback
userID, I dont have one
email ( if it is collected
amount off course
maybe the answer here is for the paysite to create an user/pwd for the user before sending them to PWC, the the postback should work as a u/p would be passed along with the link to PWC
The postback may look like
{
paysite:
txn:
userId:
Plan:
Type: ( single, Recurring )
Amount:
Fee:
Net:
Token:
IP:
timestamp:
}
If the customer does not have enough tokens, the contract would reject the transaction.
The issue becomes on recurring payments, the client may not have the token in the wallet at the time when the payment is process, no different than ach or credit card decline
Comment