old_Loopcrypto.xyz
  • Introduction
  • Supported networks and tokens
  • Loop + Frames
  • Learn
    • How Loop works
    • Core components
      • Collecting authorization
        • Enabling payment on multiple networks
        • Accepting ETH and MATIC
      • Sending payment requests
      • Checking a customer's balance & allowance
      • Receipts and reminders
      • Customer portal
    • Loop + your financial stack
      • Linking on-chain transactions with invoices in your ERP system
      • Connecting with accounting software
      • Crypto off-ramp
    • Case studies
  • Dashboard functionality
    • Subscriptions
      • Free trials, discounts and more
      • Auto-invoicing
      • Auto-cancelations
    • One-time payments
    • Scheduling outbound payments
      • Internal notes
    • Editing an upcoming payment
    • Payments for platforms
  • Integrations
    • Stripe + Loop
      • Getting setup
      • Stripe Connect setup
      • Subscriptions
        • Free trials
        • Upgrading a customer or editing a subscription's products
      • Invoicing
      • One-time payments
      • Coupon codes
      • Stripe Connect - Subscriptions
      • FAQs about Stripe integration
    • Chargebee + Loop
      • Getting setup
      • Subscriptions
      • One-time payments
      • Coupon codes
    • Quickbooks + Loop
      • Invoicing
    • Xero + Loop
      • Invoicing
    • Ghost.org + Loop
    • Zapier + Loop
    • Manually add integrations
  • Technical Docs
    • APIs
      • Entity
        • Adding child entities
        • Adding user to child entity
        • Get child entities
      • Items
        • Adding items
          • Item types
          • Categories
        • Retrieving an item
        • Updating an item
        • Deactivating an item
      • Agreements
      • Transfer requests
        • Signing transfer requests
        • Loop CLI
        • Canceling transfer requests
        • Transfer request status
        • Handling unfulfilled transfer requests
        • Validations
      • Webhooks
        • Checking webhook signatures
        • Demo App
        • Slack, Airtable, Discord, Telegram
    • Archeticture
      • Smart contract
        • Deploying your smart contract
          • Modifying smart contract properties
      • Collecting authorization
        • Checkout page
          • Additional functionality
          • Add "pay with crypto" button
        • Checkout widget
          • NPM package readme
        • Checkout parameter examples
      • Providing on-chain payment based access
        • Subscription gated communities
    • Loop SDK
      • Verify Webhook
      • Transfers
      • Error Handling
      • Generating API keys
    • Sample guide: Collect a subscription or one-time payment
    • Integrating the Loop Protocol into your dApp
      • Payroll applications
      • Loan platforms (credit cards, BNPL)
    • Security
      • API Authentication
      • Securing with signatures
      • API Trust assumptions
      • Audits
  • FAQs
  • Company Dashboard
  • Loop Portal
Powered by GitBook
On this page
  • Reasons for an unfulfilled transfer request
  • How to handle unfulfilled transfer requests
  1. Technical Docs
  2. APIs
  3. Transfer requests

Handling unfulfilled transfer requests

Loop does some validations when transfer requests are sent to our backend to ensure that only transfer requests that will be fulfilled are processed on-chain; however, there may be instances where a transaction is executed on-chain, but the transfer request was never fulfilled (i.e. no funds were transferred from the "from" wallet).

Reasons for an unfulfilled transfer request

1) the wrong signer wallet is used,

We validate that the transfer request came from an authorized source by having the details of that transfer request signed by the approved wallet (signer wallet) stored in the contract. Thus, a transfer request will not execute if the signer wallet that produced the signature in the transfer request does not match the signer wallet saved on-chain.

2) the transfer request's signature has already been processed

As a security measure, every transfer request needs a unique signature to be processed. Thus, if a request is sent with a signature that has already been processed on-chain, the transaction will fail.

3) the from wallet has an insufficient balance or token allowance

The keeper network will ignore a transfer request where the from wallet has insufficient balance or allowance. However, it could be the case that when the keeper checked the balance/allowance it was sufficient, and by the time the transaction was sent to the mempool and eventually mined on-chain, that status has changed.

4) if applicable, the inbound treasury address is incorrect

When a transfer request is executed, the contract will validate that the "to" address is the same as the inbound treasury address (if the address is saved in the contract). If the address does not match the inbound treasury address, the transfer request will not be fulfilled.

Loop does not validate on our backend that the inbound treasury address matches what is stored in the contract. Therefore, the keeper network could pick up and try to process a transfer request with an invalid treasury address.

How to handle unfulfilled transfer requests

When a transaction is processed on chain, you will receive a "transaction processed" webhook with a status (success or failed). If you receive a failed transaction and you want to reprocess the transfer request (i.e. the same parameters), you must send the request with a new invoiceID. This is because if you use the exact same 6 parameters and sign with the same wallet, the signature will be the same as the transaction that just failed and thus it will also fail (see reason 2 for failing).

PreviousTransfer request statusNextValidations

Last updated 1 year ago