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
wheretype=bank
. - This Payable type is also used for
real_time_payments
.
See Real-Time Payments for more information.
International (type=international
)
- Create this Payable when paying international vendors via local bank transfer or SWIFT.
- Your vendor must have an existing
PaymentMethod
wheretype=international
. They can create this in the Invite a Company or Accept Payment flows. - See the
delivery_methods
array in the vendor'sPaymentMethod
to determine what delivery methods are supported. - You must have an existing
PaymentMethod
wheretype=bank
to process an international transaction. - See International 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
wheretype=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.
Rate Limiting
🏁 This endpoint's rate limit is 100 calls per minute.
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
tonull
. - 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.