Send a Wire (Domestic)

POST Transaction to send a domestic wire

To send a domestic wire, you will create a transaction from a Deposit Account DEPOSIT-US to a Wire Account WIRE-US node.

Reminder

Please remember to Create Users, Oauth Users and Link Accounts (including a DEPOSIT-US node for the sender and a WIRE-US node for the recipient).

user_id :
required
string

The user ID of the user you wish to add the WIRE-US node under

BODY PARAMETER

Body Params

type :
required
string

Type of node you wish to add

info.nickname :
required
string

Nickname for the node

info.account_num :
required
string

Account number associated with the bank

info.routing_num :
required
string

Routing number associated with the bank

info.correspondent_info.routing_num :
string

Routing number of correspondent bank

info.correspondent_info.bank_name :
string

Name of correspondent bank

info.correspondent_info.address :
string

Address of correspondent bank

extra.supp_id :
string

Any ID you wish to register to the node

is_active :
boolean

If the node is indexed or marked deleted

EXAMPLE REQUEST

POST /v3.1/users/594e6da41acea2002e666987/nodes/594e6e6c12e17a002f2e39e4/trans HTTP/1.1
Host: uat-api.synapsefi.com
X-SP-USER-IP: 127.0.0.1
X-SP-USER: oauth_fyBaT5kswdlme0xQI6gSCPYKDG1Zrv8Ftj9NboJc|e83cf6ddcf778e37bfe3d48fc78a6502062fc
Content-Type: application/json

{
  "to": {
    "type": "WIRE-US",
    "id": "594e6e6c12e17a002f2e39e4"
  },
  "amount": {
    "amount": 2000.1,
    "currency": "USD"
  },
  "extra": {
    "ip": "192.168.0.1"
  }
}
from_node = '594e606212e17a002f2e3251'

body = {
  "to": {
    "type": "WIRE-US",
    "id": "594e6e6c12e17a002f2e39e4"
  },
  "amount": {
    "amount": 2000.1,
    "currency": "USD"
  },
  "extra": {
    "ip": "192.168.0.1"
  }
}

user.create_trans(from_node, body)
const fromNodeID = '594e606212e17a002f2e3251';
const body = {
  "to": {
    "type": "WIRE-US",
    "id": "594e6e6c12e17a002f2e39e4"
  },
  "amount": {
    "amount": 2000.1,
    "currency": "USD"
  },
  "extra": {
    "ip": "192.168.0.1"
  }
};

user.createTransaction(fromNodeID, body);
from_node = '594e606212e17a002f2e3251'

body = {
  "to": {
    "type": "WIRE-US",
    "id": "594e6e6c12e17a002f2e39e4"
  },
  "amount": {
    "amount": 2000.1,
    "currency": "USD"
  },
  "extra": {
    "ip": "192.168.0.1"
  }
}

user.create_transaction(node_id: from_node ,payload: body)
$to = (object)[
   "type" => "WIRE-US",
   "id" => 'to_node_id'
];
$amount = (object)[
   "amount" => 22.1,
   "currency" => "USD"
];
$extra = (object)[
   "ip" => "IP_address_of_user_device_while_creating_transaction"
];
$body = (object)[
   "to" => $to,
   "amount" => $amount,
   "extra" => $extra
];
$nodeid = '5c3d416f7b08ab0066ee8cae';
$user->create_trans($nodeid, $body);
nodeID := “594e606212e17a002f2e3251”

body := `{
  "to": {
    "type": "WIRE-US",
    "id": "594e6e6c12e17a002f2e39e4"
  },
  "amount": {
    "amount": 2000.1,
    "currency": "USD"
  },
  "extra": {
    "ip": "192.168.0.1"
  }
}`

data, err := user.CreateTransaction(nodeID, body)

2FA For Outgoing Wires

We strongly encourage requiring 2FA on the sender before you allow them to send a wire from their deposit account. This is an extra step of verification, since you cannot pull a wire back after it is sent.

EXAMPLE RESPONSE

{
  "_id": "5b57d2b4b75379005e3d60cf",
  "_links": {
    "self": {
      "href": "https://uat-api.synapsefi.com/v3.1/users/5b57d065c9f52d0059a50e63/nodes/5b57d07ef605a000497f0409/trans/5b57d2b4b75379005e3d60cf"
    }
  },
  "_v": 2,
  "amount": {
    "amount": 2000.1,
    "currency": "USD"
  },
  "client": {
    "id": "589a9ffc86c2736412ce7ea4",
    "name": "TEST TEST MEESH"
  },
  "extra": {
    "created_on": 1532482228415,
    "ip": "192.168.0.1",
    "latlon": "0,0",
    "note": "Test transaction",
    "process_on": 1532482228415,
    "same_day": false,
    "supp_id": "1122444"
  },
  "fees": [
    {
      "fee": 0.0,
      "note": "Facilitator Fee",
      "to": {
        "id": "None"
      }
    }
  ],
  "from": {
    "id": "5b57d07ef605a000497f0409",
    "meta": {},
    "nickname": "SynapsePay Test Checking Account - 8901",
    "type": "DEPOSIT-US",
    "user": {
      "_id": "5b57d065c9f52d0059a50e63",
      "legal_names": []
    }
  },
  "recent_status": {
    "date": 1532482228415,
    "note": "Transaction Created.",
    "status": "CREATED",
    "status_id": "1"
  },
  "timeline": [
    {
      "date": 1532482228415,
      "note": "Transaction Created.",
      "status": "CREATED",
      "status_id": "1"
    }
  ],
  "to": {
    "id": "5b57d07ef605a000497f0409",
    "meta": {},
    "nickname": "",
    "type": "WIRE-US",
    "user": {
      "_id": "",
      "legal_names": []
    }
  }
}

Wire Cutoff Times

Domestic wires will settle same day if created before 12PM PST.

Example Timeline

Here is an example timeline for an outgoing wire. Not all transactions will follow this exact timeline, so please do not build your logic off these times. Instead, monitor transaction status and account balance.

Note: Different banks post transactions at different times, so a user may not see their transaction marked as settled at the exact time that we mark a transaction as settled.

Description
Time
Transaction Status
status_id

User creates a transaction

Day 1, 10AM PT

CREATED

1

The transaction is submitted to our partner bank ("ODFI") at the appropriate cutoff time, assuming the transaction was not queued or canceled.

Day 1, 12PM PT

PROCESSING-DEBIT

2

User's bank ("RDFI") picks up the Wire.

Day 1, 6PM PT

PROCESSING-CREDIT

3

We mark the Transaction as Settled. It may still take time to show up in the bank account as actual settlement depends on when the receiving bank credits the funds. Settled wires should show up in the account by end of day.

Day 1, 6:05PM PT

SETTLED

4

Transaction Status

The following are different types of transaction statuses for Wires.

STATUS
STATUS_ID
DESCRIPTION

QUEUED-BY-SYNAPSE

-1

Transaction queued by Synapse

QUEUED-BY-RECEIVER

0

Transaction queued by Client

CREATED

1

Transaction Created

PROCESSING-DEBIT

2

Processing Debit

PROCESSING-CREDIT

3

Processing Credit

SETTLED

4

Transaction Settled

CANCELED

5

Transaction Canceled

RETURNED

6

Transaction Returned

QUEUED AND CANCELED TRANSACTIONS

See Transaction Codes for the full list of reasons a transaction can be queued or canceled.

To cancel a transaction yourself, DELETE the transaction. Only transactions with a CREATED or QUEUED status can be canceled. Once a transaction is processing or settled you are unable to cancel it.

Returned Transactions

Returned Transactions will be marked as returned. When possible, we will propagate the reason along with the return.

Tracking Wires

If you need to track a wire, the transaction timeline will have the OMAD # available.

timeline: [
                date: {
                        $date : 1541079381991,
                },
                note : "Transaction Created.",
                status : "CREATED",
                status_id : "1",
                date: {
                        $date : 1541079394041,
                },
                note : "transaction status updated.",
                status : "PROCESSING-DEBIT",
                status_id : "2",
                date: {
                        $date : 1541093447517,
                },
                note : "",
                status : "PROCESSING-CREDIT",
                status_id : "3",
                date: {
                        $date : 1541093448418,
                },
                note : " Wire Number 136641 IMAD: 20181101MMQFMPD1000107 OMAD: 20181101B1QGC01R068969",
                status : "SETTLED",
                status_id : "4",        ]

Subscribe to Webhooks

We recommend that you subscribe to webhooks to stay updated on the status of transactions.

Transaction Fees

By default, we deduct transaction fees from the transaction. To send the recipient 100% of the funds, designate the account you want to debit fees from.

Or take an additional fee for yourself and designate the DEPOSIT-US node you want to send fees to.

Idempotent Requests

POST calls support idempotency for safely retrying requests without accidentally performing the same operation twice. For example, if a request to create a transaction fails due to a network connection error, you can retry the request with the same idempotency key to guarantee that only a single charge is created.

To perform an idempotent request, attach a unique key to any POST request made to the API via the X-SP-IDEMPOTENCY-KEY header.

Idempotency keys expire after 24 hours.