Pass Through

The pass-through use case is when a developer just want to allow their customers to deposit an asset from one source and receive in a destination wallet address. The developer also has the option to collect revenue within the flow as well.

Check the use cases that it can serve here.

Chains, rails, and constraints

Supported Source Currency	Supported Source Rail	Supported Destination Currency	Supported Destination Rail	Quote Estimation	Minimum Order Limit	Maximum Order Limit	Estimated Settlement Time (once deposit received)	Settlement Configuration (`settlment_via`)	Rebalance Configuration (`rebalance_fee`)	Default Order Expiry Time
BTC	BITCOIN	BTC	BITCOIN	✅	0.00005	Not applicable yet	~ 1 hour	`FEE_RETENTION`	Has to be always `false`(in roadmap for full support)	1 hour
USDT	TRON	USDT	TRON	✅	2	Not applicable yet	~ 3-5 mins	`FEE_RETENTION`	Has to be always `false` (in roadmap for full support)	1 hour
ETH	ETHEREUM	ETH	ETHEREUM	✅	0.001	Not applicable yet	~ 3-5 mins	`FEE_RETENTION`	Has to be always `false` (in roadmap for full support)	1 hour

For routes where “Fee rebalancing capability” & “Quote estimation” is limited. Fin can enable both upon request of the Developer or Fin will enable themselves if it is in the roadmap.Please send request in your dedicated communication group.

Pass through quote creation:

FEE_RETENTION

curl --request POST \
  --url https://sandbox.api.fin.com/v1/transit/quote \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "order_amount": "100.00",
  "integration_type": "PASS_THROUGH",
  "settlement_config": {
    "settlement_via": "FEE_RETENTION",
    "rebalance_fee": false,
    "destination_details": {
      "wallet_address": "SOLANA_WALLET_ADDRESS",
      "currency": "ETH",
      "rail": "ETHEREUM"
    }
  },
  "developer_fee": {
    "fixed": "0.5",
    "percentage": "1"
  }
}
'

For PASS_THROUGH, rebalance_fee has to be always false .

Pass through order creation:

Without Quote ID
With Quote ID

curl --request POST \
  --url https://sandbox.api.fin.com/v1/transit/payment \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "integration_type": "PASS_THROUGH",
  "order_info": {
    "external_customer_id": "dcfed3f9-46ad-407b-87ff-3bac7c9c4c38",
    "merchant_trade_no": "841e4ba2-1234-5678-9abc-a2a45de7bd00",
    "order_amount": "100.00",
    "currency": "USDT",
    "rail": "SOLANA",
    "currency_type": "crypto"
  },
  "fin": {
    "settlement_config": {
      "settlement_via": "MARKET_ORDER",
      "destination_details": {
        "wallet_address": "Ox....",
        "currency": "PYUSD",
        "rail": "SOLANA"
      }
    },
    "developer_fee": {
      "fixed": "0.5",
      "percentage": "1"
    }
  }
}
'

curl --request POST \
  --url https://sandbox.api.fin.com/v1/transit/payment \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "integration_type": "PASS_THROUGH",
  "order_info": {
    "external_customer_id": "1a11c804-8a9b-425d-96a8-c0682f52ff04",
    "quote_id": "5831ce86-cd88-4aba-b1fd-32dcf6e1a030",
    "merchant_trade_no": "841e4ba2-1234-5678-9abc-a2a45de7bd00",
    "currency": "USDT",
    "rail": "SOLANA",
    "currency_type": "crypto"
  }
}
'

order_expiry_time for PASS_THROUGH is configurable per developer but it has to be requested by the developer to Fin and Fin will configure it in their backend.

Important Considerations

About External Customer ID

The external customer ID is required for the pass-through use case. When the same external customer ID is passed in multiple requests, the same deposit wallet address is issued for that customer. For each external customer ID, one wallet address is issued per currency and rail combination. If a wallet address doesn’t exist for an external customer ID, Fin creates a new one and issues it for the order and keeps using it for future orders.

Limits to order creation

For a particular customer there can be only 1 order per currency & rail combination. For example: Customer 1 has an open order of 0.5 BTC.BITCOIN, the customer cannot create another BTC.BITCOIN order until the existing order expires / fails / processed The default order expiry can be found above.

Response Difference for Integration Type

Integration Type	Response Field
PASS_THROUGH	`data.deposit_instruction`

Get started

Coverage

Customers and compliance

Beneficiaries

Virtual accounts

Webhooks

Move money

Operations

Orchestration Dashboard

Crypto Orchestration (Special use case)

Chains, rails, and constraints

Pass through quote creation:

Pass through order creation:

Important Considerations

About External Customer ID

Limits to order creation

Response Difference for Integration Type

​Chains, rails, and constraints

​Pass through quote creation:

​Pass through order creation:

​Important Considerations

​About External Customer ID

​Limits to order creation

​Response Difference for Integration Type

Chains, rails, and constraints

Pass through quote creation:

Pass through order creation:

Important Considerations

About External Customer ID

Limits to order creation

Response Difference for Integration Type