Ξ EVM Purchase Transactions

Specifying Price

Coinflow supports making purchases in all liquid currencies, you can configure the following properties to select the token and the amount necessary to complete the purchase:

token - Address of the token which the purchase is denominated in (if using USDC leave this empty)

amount - Amount of that token necessary to complete the purchase

📘

If using ETH or MATIC please pass 0x0000000000000000000000000000000000001010

Waiting for Transaction Confirmation

By default Coinflow will show the user a success message as soon as the transaction has passed simulation and been submitted to the chain. Because of retry logic + time to confirm we recommend keeping this default behavior as it results in a better user experience.

In the case you want the user to wait until the transaction has confirmed on chain you can add waitForHash to the transaction object you pass to the Coinflow Purchase Component.

When waitForHash=true the onSuccess hook will also include the hash in its return data.

Ex:

<CoinflowPurcahse
	...
  transaction={{
  	transaction: ...,
   	waitForHash: true,
  }}
  onSuccess={(userAddress: string, hash: string, {paymentId}: {paymentId: string}) => {
    console.log({paymentId, hash});
  }}
/>

Specifying Transaction

There are multiple different ways of purchasing Goods and Services on EVM compatible blockchains via Coinflow. Each one is specific to what you as a company are selling and how your smart contracts work under the hood. Coinflow is designed for maximum flexibility and provides options so that your company does not need to change their smart contracts.

Ask yourself the following questions to determine which option is the best for you:

1. Are you selling NFTs?
   1. Yes - Go to question 2
   2. No - Go to section Redeem with Custom Receiver Field
2. Are you using a 3rd party marketplace contract? (Such as OpenSea)
   1. Yes - Go to section Reservoir
   2. No Go to question 3
3. Do you know the ID of the NFT being delivered to the user at the time of transaction creation?
   1. Yes - Go to section Known Token ID
   2. No - Go to question 4
4. Does your program use SafeMint to mint the user an NFT?
   1. Yes - Go to section SafeMint
   2. No - Go to question 5
5. Does your program return the NFT token ID in the first 32 bytes of the function call?
   1. Yes - Go to section Returned Token ID
   2. No - Go to section Redeem with Custom Receiver Field

Redeem with Custom Receiver Field

🚧

Merchant's smart contracts might require changes

Your Smart Contract needs to implement the following functionality:

1. The payer for the purchase (ERC-20 token), should bemsg.sender
2. The smart contract method must support areceiver argument, which is the end-user's wallet that is receiving the good or service.

function (receiver: address, ...) {
   payer = msg.sender; // Will always be the Coinflow contract.
}

When passing the transaction object to the Coinflow SDK or API's please utilize the following format:

{
    {
        to: '<YOUR CONTRACT ADDRESS>', 
				data: '0x...', // Function call data of the transaction
    }
}

Reservoir

Coinflow allows customers to take advantage of Reservoir's platform allowing for the aggregation of best quotes across all marketplaces on a given chain. Utilizing reservoirs functionality prevents your developers from having to construct transactions to pass to Coinflow. All you need to pass us is the information about the NFT, and Coinflow will automatically give the user a quote for the NFT, charge their card for the amount, and send the transaction to purchase the NFT, and delivering it to the user's wallet.

When passing the transaction object to the Coinflow SDK or API's please utilize the following format:

{
  type: 'reservoir',
  items: [{
		nftContract: '0x...', // This is your NFT's contract address
		nftId: '...' // This is the ID of the NFT
	}]
}

Known Token ID

If during transaction construction, your system knows the contract address and token ID of the NFT, you can specify the NFT Token ID and no changes to your smart contract are required. The Coinflow program will automatically forward the NFT to the customer's wallet.

When passing the transaction object to the Coinflow SDK or API's please utilize the following format:

{
	transaction: {
		to: '0x...', // This is your contract's address
		data: '0x...' // This is the data for your contracts function call
	},
	nftContract: '0x...', // This is your NFT's contract address
	nftId: '...' // This is the ID of the NFT
}

SafeMint

If your contract implements Openzeppelin's SafeMint function, then no changes are required to your contract. The Coinflow contract automatically determines the Token ID, and forwards the NFT to the user.

When passing the transaction object to the Coinflow SDK or API's please utilize the following format:

{
	type: "safeMint",
	transaction: {
		to: '0x...', // This is your contract's address
		data: '0x...' // This is the data for your contracts function call
	},
}

Returned Token ID

If your contract returns the Token ID of minted NFT in the first 32 bytes of returnData, then no changes are required to your contract.

When passing the transaction object to the Coinflow SDK or API's please utilize the following format:

{
	type: "returned",
	transaction: {
		to: '0x...', // This is your contract's address
		data: '0x...' // This is the data for your contracts function call
	},
}

Token Redeem

If you know the contract address that Coinflow should be sending USDC directly to, when passing the transaction object to the Coinflow SDK or API, please use the following:

{
	type: "token",
	destination: '0x...' // Whitelisted contract/wallet address Coinflow will send USDC to
}