How can I accept token payments when minting or selling an NFT?

NFT
1

Attempting to mint NFTs with BUSD on BSC using a custom ERC721/ERC20 contract results in gas estimation failures. See the revised sample contract below:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract TokenNFT is ERC721 {
    uint256 public tokenIdCounter;
    uint256 public fee = 1e18;
    IERC20 public paymentAsset;

    constructor(address assetAddr) ERC721("TokenNFT", "TNFT") {
        paymentAsset = IERC20(assetAddr);
    }

    function createNFT(address recipient, string memory metaURI) external returns (uint256) {
        require(paymentAsset.transferFrom(msg.sender, address(this), fee), "Payment failed");
        tokenIdCounter++;
        _mint(recipient, tokenIdCounter);
        return tokenIdCounter;
    }
}
2

hey everyone, im curious if anyone has tried double checking the approve mechanism? i was having issues too and ended up realizing that my contract wasnt getting enough allowance when trying to do the token transfer. sometimes its just that simple, right? also, have u thought about the token decimals, maybe mismatched decimals could be causing the gas estimation to fail. i’ve been digging around and found that adjusting the allowance amount and making sure users have properly approved the contract for spending can help a lot. anyone else experimenting with token payments for nfts using different token standards? i’d love to hear ur experiences and what tweaks worked for u, especially if u bumped into similar gas issues. cheers!

3

hey, try checkin if your fee calc accounts for token decimls. i fixed mine by adjusting the approve amt and converting fee properly. often a tiny miscalc in decimals can mess up gas estimation. hope it helps, cheers!

4

I encountered a similar issue when attempting to accept token payments while minting NFTs. It turned out that the problem wasn’t solely in the allowance but also in how the fee was represented. I discovered that the BUSD token, with its own decimals, requires careful conversion of the fee amount, and improperly scaled values can lead to gas estimation failures. I eventually resolved the problem by explicitly converting token units before performing the transfer, which ensured the allowances were properly checked. Analyzing transaction logs helped pinpoint the discrepancy between expected and actual token amounts.

5

hey everyone, i wanna share some thoughts on this one. ive been tinkering with a similar token payment flow and noticed that sometimes the contract interactions can be a bit tricky when it comes to handling token decimals. one thing i ran into was that even if you set everything up properly on the nft side, slight mismatches in the token contract implementation (and sometimes even the way transferFrom is handled) can mess things up and lead to gas estimation issues.

what worked for me was actually simplifying the process a bit: i added some extra checks before initiating the transfer, making sure the contract had a proper balance and that the fee was really correctly scaled to the token decimals. i also made sure my test transactions succeeded on a testnet first, so i could debug all issues before deploying on mainnet.

what have you guys tried so far? does anyone have experience with tokens that behave a little differently or any ideas on how to better simulate the transaction beforehand? would love to hear ur ideas and any pitfalls u might’ve run into in this process. cheers and thanks for the discussion!

6

hey, check that your token fee is correctly scaled to decimals of the token. sometimes the BUSD convertin get’s off, making transferFrom fail. also double chk if allowance is high enuf. i found proper conversion fixed my gas issues.