Types of Payables

Routable supports creating five different types of Payables.

Bank Transfer (type=ach)

  • Create this Payable when you explicitly want to pay your vendor via bank transfer.
  • Your vendor must have an existing PaymentMethod where type=bank.
  • This Payable type is also used for real_time_payments.
    See Real-Time Payments for more information.

Cross-Border (type=international)

  • Create this Payable when paying cross-border vendors via local bank transfer or SWIFT.
  • Your vendor must have an existing PaymentMethod where type=international. They can create this in the Invite a Company or Accept Payment flows.
  • See the delivery_methods array in the vendor's PaymentMethod to determine what delivery methods are supported.
  • You must have an existing PaymentMethod where type=bank to process an cross-border transaction.
  • See Cross-Border Payments for details.

Check (type=check)

  • Create this Payable when you explicitly want to pay your vendor via check.
  • Your vendor must have an existing PaymentMethod where type=address.

Vendor Choice (type=vendor_choice)

  • Create this Payable when you want your vendor to be able to choose their preferred payment method.
  • You may use this when your vendor has no existing payment methods and they will be prompted to submit a payment method via our onboarding flow.

External (type=external)

  • Create this Payable when you want to track a payment that was already made outside of Routable.

Idempotency Key

We highly recommend you supply an idempotency key when creating Payables to prevent duplicate requests. These keys are stored for a period of 24 hours.

If a request fails due to a network error, you can safely retry the same request with the same key and guarantee that your request had exactly one effect.

When a request is sent with an idempotency key for an already created resource, the response object for the existing resource will be returned.

All requests with the same key will be considered attempts for the same request. It is therefore important that you use unique keys. We suggest using random values, such as UUIDs.

Status Codes

Please note that it is possible for this endpoint to return a 202 response, which indicates that we are still processing the request.

To ensure that the payment has been created, you may attempt to retrieve it using the returned ID or self link.

Scheduling Payables

Routable supports 3 different ways of scheduling your Payables based on the value supplied for send_on.

Sending a Payable Today

  • To send a Payable today, set it to today's date in Pacific time.
  • Use this when you want to send a payable ASAP.

Sending a Payable in the Future

  • To send a Payable in the future, set send_on to a future date in Pacific time.
  • Use this when you want to send a payable in the future.

Sending a Payable with no defined date

  • To create a Payable with no specified date, set send_on to null.
  • Use this when you want to prepare a payable to be sent. This can be useful when testing out your integration.

Default Contacts

When sending Payables via our API, we will notify all contacts associated with the company based on the values specified for their default_contact_for_payable_and_receivable field.

Default Approvals

When sending Payables via our API and a payable requires approvals per your approval settings we will automatically fill in the appropriate team members.

We do this by finding all applicable levels of approval and requesting approvals from all team members.

For example, you can set up your account so that:

  • Any Payable over $1,000 requires a first level approval from either Angela or Oscar.
  • Any Payable over $2,000 requires a second level approval from both Michael and Andy.

When creating a Payable for $1,100 the API would request approval from both Angela and Oscar.

When creating a Payable for $2,100 the API would request approval from both Michael and Andy for the second level as well as Angela and Oscar on the first level.

Language
Authentication
Bearer
URL