This request triggers the issuance or remittance of funds with various options to customize how the payment is sent. With this endpoint, you can send payments either as regular ACH transactions (eg, Standard and Same Day ACH), or via ACHNow.

For now, this endpoint can be used to move funds between Sila Wallets, Virtual Accounts, and linked bank accounts, but will be opened up to accepting many different payment instrument options as the source or the destination. The CKO integration is supported.

❗️

IMPORTANT - RfP (Request for Payment) Notifications

Please be aware that RfP notifications come from end users' respective banking institutions and are NOT within Sila's environment or control.

We recommend advising your end users to verify their notifications are set up correctly with their respective banking institution.

If your end users are having trouble with receiving notifications, please reach out to the end user's banking institution.

Using this endpoint

• You MUST be approved by Sila before using ACHNow or instant rail functionality.
• You MUST use this endpoint to use ACHNow, RTP, and FedNow functionality. /issue_sila and /redeem_sila endpoints do not support these features.
• This endpoint is only accessible through HTTP requests.
• We are NOT updating SDKs to support this endpoint.

Sending an ACH transaction via Instant Settlement

When an ACH payment is sent via Instant Settlement, the Sila-side location is credited or debited immediately. Because we are not yet able to control the routes themselves, the transaction may not land in the outside account until later.

If you would like the payment to land as soon as possible to the outside account, we recommend making use of the Same Day ACH method.

Request

🚧

RTP and FedNow

Currently:

• RTP is available for both push and pull transactions (Sila wallet <> bank account)
• FedNow is only available for push transactions (Sila wallet > bank account)

Requirements

• Source of funds and destination for those funds are both required for transacting.
• Either the source or the destination must be a Sila-associated or Sila-linked account or wallet.
• Use route for specific route options like standard and Same Day ACH, instant settlement, card, and RTP.
  • Your app must be enabled for instant settlement, the Checkout integration, or RTP to make use of those features.
  • NOTE: Because the default behavior is fastest, it is STRONGLY recommended that if you wish to use Standard ACH that you specify this in the route field.
• Use route_selection_behavior for ACHNow and behavior (fastest or cheapest) selections.
• If neither a route or route_selection_behavior are provided, the request will default to route_selection_behavior = fastest. Please see How Payment Route is Determined chart below for more.
• route and route_selection_behavior are mutually exclusive. Provide one or the other, NOT both, which will result in a 400 error.
• The difference between route_selection_behavior = ACHNow and route_selection_behavior = fastest: ACHNow will trigger a cascading behavior - trying the fastest route, then next fastest, and so on. fastest will try the fastest route available, but will not cascade down to try the next fastest if that fails.

📘

Transaction Amount in Decimal Units

Please be aware that the amount value for this endpoint is in decimal units, just like /issue and /redeem.

EX:

Transaction for $10 USD

/transact amount value = 1000

🚧

ACHNow Amount in Sandbox

If testing ACHNow in Sandbox, the amount MUST be $10.00 or less, or you will receive a 400 error.

Authorization / Authentication

Apps using Access Token Authorization

Use a valid access token in an Authorization: Bearer request header.

See Authenticating with an Access Token for more details.

NOTE: Sila will support existing customers with ECDSA apps. New customers implementing ACHNow must use the JWT access token.

POST /0.2/transact HTTP/1.1
sandbox.silamoney.com
Content-Type: application/json
Authorization: Bearer [GENERATED JWT TOKEN HERE]

{
  "header": {
    "created": 1234567890, //required
    "app_handle": "handle.silamoney.eth", // required
    "user_handle":"user.silamoney.eth", // required
    "version": "0.2", // optional
    "reference": "<your unique id>" // optional
  }, 
  "amount": 1000, //required
  "source_id": "<ID to uniquely identify where funds are originating from>", // required
  "destination_id": "<ID to uniquely identify the destination of funds>", // required
  "route": "<how you want payment sent>", // required for card transactions
  "route_selection_behavior": "fastest or cheapest", // optional, ACHNow only
  "description": "transaction descriptor", // optional
  "transaction_idempotency_id": "<UUID to uniquely identify a transaction for idempotency>", // optional
  "customer_reference": "customer chosen reference string", // optional
  "ach_attributes": { // for ACH transactions, optional
    "ach_descriptor": "ach descriptor in the NACHA file", // optional
    "sec_code": "3-character SEC code" // optional
    }
}

***

HTTP/1.1 200 OK

{
  "reference": "<your unique id>",
  "message": "Transaction submitted to the processing queue.",
  "success": true,
  "status": "SUCCESS",
  "response_time_ms": "171", 
  "transaction_id": "UUID of the submitted transaction",
  "route_selected": "payement method used to move funds",
  "description": "optional description for the transaction"
}

Request Attributes

ACH-Specific Attributes

Responses

How is the Payment Route Determined?

Below is a table that can be used to help determine which payment route will be used in which case.

The "->" represents a fall back, if the method to the left of the arrow is not configured then the method to the right of the arrow will be used.

Payment routes in order of speed (fastest to slowest):

1. Instant Settlement (instant)
2. RTP (instant)
3. Same Day ACH (1 day)
4. Standard ACH (approx. 3 days)

Payment routes in order of cost (cheapest to most expensive):

1. Standard ACH
2. Same Day ACH
3. RTP
4. Instant Settlement

Please note that Instant Settlement is only valid for transactions from a bank account to a Sila Wallet.

Mocking Errors

You can set the Sila-Mock-Error header in a request in order to mock an error in Sandbox. The error mocked will be based on the value of the header. Please see the table below for the which values mock which errors:

Note that if the header does not apply to the transaction information provided, a 400 error will be returned.