Scope: Send Money (requires IP whitelist)

🚧
Valid uses for the transaction API
You may not use the Mercury API for any activity that requires a license or registration from any governmental authority in the U.S., or any authority you are subject to, without Mercury's approval in advance. This includes but is not limited to any activity type described in the definition of a Money Services Business, or any State-regulated financial services such as Money Transmission.
Here are some acceptable uses:

Paying invoices for your company

Automating bills and other payments

Here are some unacceptable uses:

Providing cash advances

Currency conversion services

Escrow services

Building out marketplaces to facilitate payments

Marketplace - Any business model that involves receiving currency (or other value that substitutes for currency), and transferring that currency to another person by any means, including through a mobile application, through a network of persons, or through an informal value transfer system

Contact api@mercury.com if you'd like to confirm your use case is allowed. We especially recommend this if you'd describe your company as a financial services company.

Note that attempting to create a duplicate transaction (same recipient, same account, same amount) within 24 hours would result in an HTTP 400 error, even if you use different idempotency keys for each attempt. If you want this restriction removed, please reach out to support.

📘
Idempotency Keys
Each request to create a transaction must provide an idempotency key which uniquely identifies the transaction. Repeated requests with the same idempotency key will not create a duplicate transaction, and will instead return HTTP 409 (conflict) with the normal API response for that transaction.
This approach makes it safe to retry creating a transaction, in case it is unclear that the transaction processed (for example, in case of a network error or your server crashing after the request is sent).
The idempotency key itself can be any value uniquely identifying the transaction. We recommend a UUID V4 or auto-incrementing database column for a general purpose solution.
Alternatively, you can also use a more semantic key. For example, if you pay "Recipient A" monthly, your idempotency key could be "Recipient A January". This would prevent duplicate transactions if you tried to pay Recipient A twice in January accidentally.
Your code should look something like this:

Insert a record of attempting a transaction into your database. This should include your own metadata about the transaction (e.g. recipient ID, amount, etc.), plus an idempotency key and a value noting that the transaction hasn't been attempted. Example query using PostgreSQL:
INSERT INTO transactions (id, recipient_id, amount, attempted) VALUES 	(uuid_generate_v4(), recip1, 10.20, false) RETURNING id;
Make the HTTP request to Mercury to create the transaction

Update the database record to note that the transaction was attempted. Example using PostgreSQL:
UPDATE transactions SET attempted = true WHERE id = <id from step 1>;
You can then set up an alert or retry logic to look for transactions that are in your database but not marked as attempted, which would suggest that either step 2 or 3 failed. The idempotency key will help prevent duplicate payments if only step 3 failed.

ℹ️
Payment Methods
When using domesticWire as a paymentMethod:

purpose.simple.category is required.

purpose.simple.additionalInfo:

Required when purpose.simple.category is:

Vendor (vendor name)

Contractor (contractor name)

Other (payment description)

Optional for:

Subsidiary

Not allowed for all other categories

200