Skip to main content
A customer mailed you a check for two invoices. This guide deposits it into your Nickel Banking account from photos of its front and back, marks both invoices paid in the same request, and follows the deposit until the bank settles it. For accounts, deposit states and what applying a deposit means, see How Nickel Banking Works.
Before you start: You need a sandbox API key (see the Quickstart), an open Nickel Banking account, and a photo of each side of the check. The key’s team member needs permission to deposit into Nickel Banking and to see its deposits.
Amounts are always in cents. A check for $1,550.55 is 155055.
In the API, an invoice is a payment link (/paymentLink). This guide says “invoice” in prose and keeps the API’s names in paths and fields.
1

Find the account

An organization can have more than one Nickel Banking account, so every deposit names the one it goes into. List them with GET /nickelBanking/accounts:
The response below is illustrative:
Keep the account’s id. A 403 here means the key can’t see Nickel Banking; its code and message say why.
2

Deposit the check and apply it

Send both photos with POST /nickelBanking/checkDeposits as multipart/form-data. Give the check’s amount exactly as written on it. applications is a JSON array of the invoices the check pays: here $1,000.00 to one and $550.55 to another.
The response below is illustrative:
Both invoices read paid as soon as this returns, even though the check is still PROCESSING. If any application is refused, for example because it’s more than an invoice has left to pay, nothing is deposited and the response says which.
Retrying is safe. The photos identify the check, so sending the same two photos again returns this deposit and nothing reaches the bank twice. Applications sent with a repeat aren’t written, so check applications on what comes back.
3

Or apply it later

If you don’t know which invoices a check pays when you deposit it, leave out applications and apply the deposit afterward with POST /nickelBanking/checkDeposits/{checkDepositId}/apply:
The response has the same shape as recording an external payment: the new externalPayment, with nickelBankingTransferId set to the deposit’s transferId, and the updated paymentLink.Always send an externalReferenceId. If the request times out and you retry with the same one, Nickel returns the application it already made instead of applying the deposit twice.
Don’t also record the check with POST /paymentLink/{paymentLinkId}/externalPayment. The money is already in your account, and recording it as outside money too counts the same check twice.
4

Follow the deposit

The deposit stays PROCESSING while the bank reviews the check, and a deposited check can still be reversed after that. Rather than polling, let Nickel tell you: each change below sends a webhook to the endpoint you registered in Receive webhooks.The event carries only the deposit’s id. Fetch its current state with GET /nickelBanking/checkDeposits/{checkDepositId}, which answers in the same shape as the deposit above:
A voided application’s voidReason says which of these happened. To catch up after your endpoint was down, list deposits with GET /nickelBanking/checkDeposits, filtered by status; to find the ones that still have money to apply, filter with unappliedOnly=true.

Where to go next

How Nickel Banking works

Accounts, balances, deposits and transactions.

Send an invoice

Create the payment links a check pays.

Receive webhooks

Register the endpoint the deposit’s events go to.