![]() |
crypto payments , recurring payments
If I build a crypto payment contract and dapp charging .75 per transaction and 6% of the amount as a fee.
Would u use it? Would you pay setup fee? |
Quote:
|
I am thinking of only accepting erc20 stable coins.
BUSD and TETHER , once tokens are collected they will be sent to the paysite wallet and a postback transaction send. recurring transaction will be processes once a day for any payments that are due. |
I was hoping there would be more interest ;(
wondered if it is worth persuing |
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.
|
I can understand that.
What would a fair cost be? I lowered the service cost to .50 + 3% I have even contemplated doing a fixed $100 fee for the first 6 month of service, if I can get 100 or so signed up |
I wouldn´t look at paying a set up fee, a % per transaction, yes.
|
Definitely yes i'd
|
Quote:
|
that would be a nice idea
|
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) |
something like dat.
What I am thinking is click on link to Pay With Crypto 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 |
So would a fee of 0.50 + 3% of the transaction be reasonable ?
I am still thinking offering a intro offer for $100 covers all fees for 6 months. |
All times are GMT -7. The time now is 05:40 PM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc