Payments

Let's examine what is required from your users in order for them to be able to consume/purchase a given service from your dApp.

Your user must have small amount of ethers in order for him to be able to execute Ethereum transactions and cover the gas costs. Another resource that is required in many cases is ERC20 compatible token that is used as value/credits or similar in order to "buy" the actual service from your dApp.

The two assets described above must be provided to your users in order for them to be able to execute the transactions and successfully consume your service.

In the case of LimePay, the liquidity of those assets is provided by you (the dApp). They are stored in a special smart contract used as an escrow.

Payments in LimePay represent the lifecycle from initial creation up until the successful execution of the Ethereum transactions (charging of fiat funds, funding the user and executing his transactions).

Payments are created every time you want your users to execute Ethereum transactions using LimePay. There are two types of payments: Fiat and Relayed. Depending on the use-case you would want to process the one or the other.

Fiat Payments

Fiat payments are used when your user has to be charged with credit/debit card, because he does not have ethers/tokens at all. In this case the user pays for the ethers and tokens that are required in order for him to execute the required Ethereum transactions, rendering the service that you are providing.

NOTE: When you are processing payments, the credit card number, CVV and expiration date are securely transferred and never hit your servers, therefore the PCI Compliant burden that you hold is limited to the simplest and minimal SAQ-A level (you have fully outsourced all cardholder data functions).

Relayed Payments

Relayed payments are used when you want to sponsor your user with the gas required for him to execute his transactions. In this scenario, you as a service provider decide to pay the gas costs of the user in order for him to be able to consume your service. Therefore using Relayed payments, the user is not charged with fiat funds.

Payment Lifecycle

Payments can have 4 statuses: NEW, PROCESSING, SUCCESSFUL and FAILED.

The status of the payment is NEW when created. The status goes to PROCESSING once the payment is send for processing. Once all of the transactions are execute, the payment goes to SUCCESSFUL state.

Transaction Lifecycle

Every payment contains ethereum transactions that must be executed. Every transaction has 4 statuses: PENDING, PROCESSING, SUCCESSFUL and FAILED. The initial state of the transactions is PENDING. Once the transaction is broadcasted it goes to PROCESSING state. After the transaction is mined, the status is SUCCESSFUL. FAILED transaction status can occur once transaction reverts.

Escrow Contract

Escrow Smart Contract will be deployed for your dApp. It will be used only for the funding of your users with the required ethers/tokens. You as a dApp developer must deposit the funds which will be used for funding of your users. Through the escrow, your users will acquire ethers/tokens. Those funds will get to your dApp's smart contracts after the execution of the transactions.

NOTE: The Escrow contract uses authorization signatures, meaning that LimePay is not a custodian of the funds. Only you as a dApp owner have the permissions to withdraw or authorise a funding of user. LimePay does not have any control of the funds stored in the Escrow contract.

F.A.Q

Can users execute more than one transaction?

Yes! Your users can execute any number of transactions as long as they have the required ethers to cover their gas costs. You as developer determine the transactions that your users execute. In many cases there are two transactions that are executed. The first one being an ERC20 Approve transaction and the second one the specific dApp transaction that renders the service in exchange for the tokens that were approved in the first transaction.

What if the user signs different transaction?

LimePay is validating the signed by the user transactions against the ones that you provide when you are creating the payment, meaning that your user will certainly execute the transactions that you specified on payment creation.

What happens when there are no funds in the Escrow contract?

Once the funds in your Escrow contract drop and you can no longer fund your users, you will not be able to process new payments until you deposit more funds into the Escrow.