# Visa testing credit card gas fee payments through Paymaster Smart Contracts

Source: https://usa.visa.com/solutions/crypto/paying-blockchain-gas-fees-with-card.html
Kiwi News: https://news.kiwistand.com/stories/Visa-testing-credit-card-gas-fee-payments-through-Paymaster-Smart-Contracts?index=0x64d7243eef580f0d929282543f3caf34569b23a234f043c8bd94a59d6880d46a87d08784
Submitted by miragenesi.eth on 2023-08-12 UTC, 4 upvotes, 0 comments

## Summary

Visa ran an experiment in which users pay blockchain gas fees with Visa cards, using a paymaster web service built on Cybersource and a Verifying Paymaster Smart Contract under the ERC-4337 standard. The wallet sends the User Operation and card credentials to the web service, which charges the user in fiat currency and then produces a digital signature over the calldata and gas fee information, valid for a set time window. The wallet appends this signature and window to the User Operation, and the paymaster contract checks it, covering gas costs only if the signature is correct. The time window guards against users paying in fiat when ETH is cheap and later redeeming the signature when it is more expensive. The article says merchants or dApps could run their own paymaster solutions using this approach, but notes the product is still in development and its final version may differ.

## Article

As shown in Figure 5, in our implementation, when the user intends to initiate an operation over the blockchain, the wallet first generates a User Operation request with information on the action they are trying to conduct (i.e., calldata) and the maximum processing cost of the action (i.e., parameters related to gas fees). More specifically, parameters specifying a gas limit determine the maximum amount of computation that should be budgeted for the operation and the gas fee determines the cost for each unit of computation.

Instead of sending the User Operation request to the blockchain right away, the wallet first sends the User Operation, along with Visa card credentials, to the paymaster web service (step 2 of Figure 5). The web service will use the gas fee information to calculate the appropriate cost to charge the user in fiat currency and based on the card credentials provided, the Card-issuer may elect to authorize the card payment. For the web service’s payment acceptance solution, we used Visa's own Cybersource. Cybersource provides developers with the necessary SDKs and APIs to enable merchants to accept digital payments.

In our experiment, after the payment is processed via Cybersource, the web service produces a digital signature over the relevant data in the User Operation, including the calldata and gas fee information (step 3). It also determines a time range of when this signature is valid. Specifying a time window is important because the value of ETH and other native tokens are dynamic on Ethereum and other EVM chains. Without precautions, a user could exploit the lack of synchrony between the two parts of the paymaster, paying offchain in fiat money when the ETH cost is lower, only to use the signature later when it is higher and have the paymaster contract bear the cost difference. The web service sends the digital signature back to the wallet. Beyond this point, any changes that the wallet makes to the relevant parameters of the User Operation would cause a mismatch with the digital signature and the Verifying Paymaster Smart Contract would detect the discrepancy.

The wallet receives the digital signature and the time window from the web service and appends this information, along with the onchain address for the paymaster contract, as the paymaster parameter of the User Operation. Now, when all parts of the User Operation are complete, the wallet will be enabled to sign and send it to the blockchain (step 4). On the blockchain, as part of the User Operation processing flow defined by the ERC-4337 standard, the paymaster contract will receive the User Operation data, which should include the digital signature from the paymaster web service. If there is anything wrong with the data provided (an incorrect signature, invalid time window, etc.), the paymaster contract is designed to raise an error and will not cover the gas costs. If the signature is verified to be correct, this means the web service received the card payment to enable the processing cost of this User Operation. The paymaster contract will raise no errors and will handle the cost and the User Operation will execute (step 5).

Reducing friction on blockchain

The intricacies and complexities of blockchain-based transactions have been a significant stumbling block for many users, creating a challenging learning curve and increasing user friction. However, our experiment aims to offer a promising approach to substantially addressing these challenges. By leveraging the innovative concept of a paymaster, in conjunction with Account Abstraction and the ERC-4337 standard, we explored the potential for a process that could redefine blockchain-based transactions.

Account Abstraction allows developers to design new flows that help reduce friction for all kinds of value interchange. Our experiment demonstrates that developers can implement this solution with existing payments infrastructure. Merchants or decentralized applications (dApps) could run their own paymaster solution as a means to help improve customer experience by accepting gas fee payments using Visa cards. Alternatively, existing wallet and paymaster service providers could offer a card-based gas fee payment choice for general use alongside their other paymaster offerings. The realization of such a potential solution helps set the stage for a more accessible and user-friendly approach to digital transactions.

For companies working on this forefront, our product, research and engineering teams are happy to discuss ideas in programmable payments. Reach out to Visa Crypto at [email protected] to learn more about our research interests and activities in the crypto ecosystem. Head over to Stablecoin solutions for more consumer insights, best practices and innovative approaches to the blockchain through our research.

This document is intended for illustrative purposes only. It contains depictions of a product in development and should be understood as a representation of the potential features of the fully deployed product. The final version of this product may not contain all the features described in this presentation.