Skip to navigation
Funding

Funding disclosures

View as Markdown

Before a user can fund with a debit card, a digital wallet, or ACH, they must have signed the funding disclosures that apply to that flow. Your integration resolves the right documents, shows each one, collects the signature, and confirms it was stored.

These endpoints are Live-only. Do not send them to the Demo base URL.

Prerequisites

Your integration needs:

  • a bearer access token for the user;
  • the user’s numeric user ID;
  • the clearingHouseId of the account being funded, from the account record;
  • a PDF viewer in your client. The preview is returned as base64, not as a URL.

Decide which documents the flow needs

Two documents exist. Which ones apply depends on the funding flow and on whether the user is adding a payment method or funding with one already saved.

FlowDocuments, in signing order
ACHPayment Processor Disclosure and Authorization
Add a debit cardPayment Processor Disclosure and Authorization, then Form of Risk Disclosure and Customer Authorization
Fund with a saved debit cardOnly those not already signed
Apple Pay or Google PayPayment Processor Disclosure and Authorization, then Form of Risk Disclosure and Customer Authorization

A previously signed document satisfies the requirement, with one exception: adding a payment method re-collects the payment processor authorization every time, even when the user signed it for an earlier method. The form of risk disclosure is collected once.

Resolve the template ID by name

Document names are the stable identifier. The numeric agreementDocumentTemplateId differs between environments and between clearing houses, so resolve it at runtime and never hard-code it.

Call agreementDocumentTemplateList and match on the exact name:

GET /v1/agreementDocumentTemplate/list

A name can appear several times, once per clearing house. Select in this order:

  1. the row whose clearingHouseId matches the account’s;
  2. otherwise the row with no clearingHouseId.

Never take the first match, and never use a row belonging to a different clearing house.

Check what the user has already signed

Read the user’s signed records with userSignedDocumentLDependents:

GET /v1/userSignedDocument/ldeps?masterids=654321

A document counts as signed when a record carries its documentName. Compare against the list from the previous step and drop the documents the flow does not still need.

A signed record is not scoped to a clearing house. If the same document name exists for more than one clearing house, a record from either satisfies the check.

Preview the document

Retrieve the PDF with downloadUserDocumentPreview, using the resolved template ID:

{
  "agreementDocumentTemplateId": 186,
  "pdfFields": {}
}

The response returns the document in content as base64. Decode it and display it to the user.

Do not enable your sign control until the document has actually rendered. Treating a successful response as proof the user saw the document means collecting a signature on an unread disclosure.

Collect the signature

Call signUserDocument once per document:

{
  "agreementDocumentTemplateId": 186,
  "signature": "Jane Doe",
  "date": "10/12/2026",
  "pdfFields": {},
  "allowMultiple": true
}
FieldRequirement
signatureMust match the full name on the applicant’s contact record. A mismatch is rejected with Signature should be the same as full name of the applicant.
dateMM/DD/YYYY.
pdfFieldsSend {} for both funding disclosures.
allowMultipletrue permits a further signature for a template the user has already signed. Set it when you are adding a payment method and re-collecting the payment processor authorization. Omitted or false, a second attempt is refused with User already has a signed <template name>.

A successful response carries userSignedDocumentId and successHashCode.

Confirm the signature was stored

Re-read userSignedDocument/ldeps and look for the userSignedDocumentId the sign call returned.

Once signUserDocument has returned successfully, the signature is stored. If the re-read does not show it yet, retry the read — do not call signUserDocument again. allowMultiple: true means a second call records a duplicate signature.

Repeat the preview, sign, and confirm steps for each remaining document before starting the deposit.

Handle responses and rate limits

These endpoints return business failures in an HTTP 200 response. Always inspect errorText rather than relying on the status code.

Check every HTTP 200 body for p-ticket. Follow the penalty-ticket procedure rather than treating the response as a successful signature.

Next steps