Payment
Queries
paymentAuthenticatedFetches a single payment by its id. Returns null when no payment matches.paymentsAuthenticatedLists payments as a Relay-style, cursor-paginated connection. Page forward by starting with first: N, then passing the previous response's pageInfo.endCursor back as after (repeat while pageInfo.hasNextPage); page backward with last + before. Scope the results with one of orgId / agencyId / configurationId and/or a start/end date range via PaymentsInput. See PaymentConnection for the response shape. Results are ordered newest first.
Mutations
paymentRefundAuthenticatedRefunds a payment, in full or in part, through the provider that took it. What a successful response means depends on that provider. NMI answers synchronously, so the refund is COMPLETED. CLP accepts the refund and settles it later, so the refund is RECEIVED and completes when the provider confirms it. Plaid payments cannot be refunded through this API yet. A refund the provider refuses is an error rather than a result. Supply an idempotencyKey so a retried request returns the refund the first request created instead of issuing a second one.paymentMethodChargeAuthenticatedCharges a stored payment method. A refusal by the provider is reported in the result rather than raised as an error, so check success before reading payment. The method must be Active — charging an Expired, Invalid or deleted method fails. Supply an idempotencyKey so a retried request does not charge the customer twice.chargePaymentMethodAuthenticatedDeprecatedThe earlier name of paymentMethodCharge, kept for clients that already use it. Identical in every way; new integrations should call paymentMethodCharge.
Types
AmountA monetary amount with up to two decimal places. Ex. 111.11ChargePaymentMethodInputThe earlier name of PaymentMethodChargeInput, kept so an operation written against the deprecated chargePaymentMethod still validates. Identical field for field; new integrations should use PaymentMethodChargeInput.ChargePaymentMethodResultOutcome of charging a stored payment method. A refusal is a normal result rather than an error: success is false, message carries the provider's reason, and payment is null.ContactContactIdvDocumentA captured identity document from a contact's Plaid documentary verification.ContactIdvDocumentImageA single captured image belonging to a ContactIdvDocument. Plaid-hosted and expiring.ContactIdvSessionDetailDetails of a contact's Plaid identity-verification session, fetched on demand from Plaid. The public graph exposes the timestamps, the captured selfie video, the captured identity documents, and the individual check outcomes; the remaining fields — including the raw Plaid pass-throughs they are derived from — are private-graph only.ContactIdvSessionStatusWhere a contact's verification stands. Mirrors the shared IdvSessionStatus but is declared separately so the contact graph's public surface does not depend on a type owned by the application module.ContactVaultTokensInputFilter and pagination for 'Contact.vaultTokens'. The contact is the one the field hangs off, so there is no contact or organization filter to pass. Pagination works as on 'VaultTokensInput': forward with first + after, backward with last + before, and a request that combines the two directions is rejected as a validation error.CurrencyThree letter ISO 4217 currency code. Ex. USDDateTimeISO 8601 formatted date time. Ex. 2023-11-23T14:30:00ZEmailAn email addressGlobalAddressAddress of a physical locationGlobalAddressInputAddress of a physical locationIdvFacialComparisonStatusHow the captured selfie compared against the face on the captured identity document. NoInput means one of the two was never captured.IdvLivenessStatusWhether the captured selfie passed liveness detection — that a live person was present rather than a photograph or a screen.IdvMatchSummaryHow one value that the contact supplied compared against the data sources that Plaid checked it against. NoData means Plaid held nothing to compare with; NoInput means the contact supplied nothing to compare.PageInfoPageInfo type for cursor-based pagination following the Relay specification for cursor based pagination.PaymentPaymentConnectionA page of payments following the [Relay Connection spec](https://relay.dev/graphql/connections.htm). edges holds the payments in this page (each with its cursor) and pageInfo describes whether more pages exist in each direction plus the cursors that bound this page. Typical "load more" loop: read edges[].node for the data, then if pageInfo.hasNextPage is true request the next page with payments(input: { first: N, after: pageInfo.endCursor, ...same filters }).PaymentEdgeA single element of a PaymentConnection page: the payment itself (node) plus the opaque cursor that points at it. Pass a cursor back as after (forward) or before (backward) to page relative to this row.PaymentInstrumentWhat moved the money, as distinct from the provider that processed it. A provider offers more than one: a CLP payment is a card or an ACH debit depending on what the shopper chose. The bank rails name their direction, because one rail both collects and pays out. A debit pulls from the customer's account, which is every payment the platform takes today; a credit pushes to it. `AchCredit` is an ACH credit entry and has nothing to do with a credit card — how a card is funded is `PaymentMethodCard.funding`. Cards carry no direction here because pushing to one is a different scheme operation, not the same charge reversed. Distinct from `Payment.paymentMethod`, which is the stored instrument a payment was charged against and exists only for payments taken from a method on file. This is recorded for every payment.PaymentMethodA payment instrument stored against a contact so it can be charged again without the customer re-entering it. A payment method is created by completing a payment session whose `storePaymentMethod` was not `Disabled`, and charged afterwards with `paymentMethodCharge`. Payment options that are unsuitable for storing are not offered during such a session — consumer financing such as FlexPay, for example, applies to a single purchase and cannot act as a method on file.PaymentMethodBankAccountBank account detail for a stored payment method whose type is BankAccount.PaymentMethodBankAccountTypeThe kind of bank account a stored payment method debits.PaymentMethodCardCard detail for a stored payment method whose type is Card.PaymentMethodCardFundingHow a stored card funds a payment, when the provider reports it.PaymentMethodChargeInputDetails of a payment to run against a stored payment method. The currency must match the currency the method was stored under.PaymentMethodConnectionA page of payment methods following the [Relay Connection spec](https://relay.dev/graphql/connections.htm). edges holds the payment methods in this page (each with its cursor) and pageInfo describes whether more pages exist in each direction plus the cursors that bound this page.PaymentMethodEdgeA single element of a PaymentMethodConnection page: the payment method itself (node) plus the opaque cursor that points at it. Pass a cursor back as `after` (forward) or `before` (backward) to page relative to this row.PaymentMethodsInputFilter and pagination for a payment methods connection. Pagination is Relay cursor-based, not page/offset based — see the [Relay Connections spec](https://relay.dev/graphql/connections.htm). Page forward with first + after, or backward with last + before; never mix the two directions in a single call. Cursors are opaque strings taken from a previous response's pageInfo (or edges[].cursor) — treat them as black boxes, don't build or parse them yourself.PaymentMethodStatusWhether a stored payment method can still be charged.PaymentMethodTypeThe kind of instrument a stored payment method holds.PaymentProviderPaymentRefundPaymentRefundInputPaymentRefundStatusPaymentSessionRepresents a payment session a customer can use to make a payment. This session is used to configuration and setup the payment experience for an individual customer's session during checkout.PaymentSessionContactRefMerchant provide contact information for use during a payment session.PaymentSessionContactRefInputMerchant provide contact information to use when creating a payment session.PaymentSessionInvoiceLineItemRefMerchant provided invoice line item information for use during a payment session.PaymentSessionInvoiceLineItemRefInputMerchant provided invoice line item detail used to create a payment session.PaymentSessionInvoiceRefMerchant provided invoice information for use during a payment session.PaymentSessionInvoiceRefInputMerchant provided invoice detail used to create a payment session.PaymentSessionStatusPaymentsInputFilter and pagination for the payments connection. Pagination is Relay cursor-based, not page/offset based — see the [Relay Connections spec](https://relay.dev/graphql/connections.htm). Page forward with first + after, or backward with last + before; never mix the two directions in a single call. Cursors are opaque strings taken from a previous response's pageInfo (or edges[].cursor) — treat them as black boxes, don't build or parse them yourself. Scope the list by supplying at most one of orgId, agencyId, or configurationId (omit all three to list every payment), and optionally a start/end payment-date range. Results are ordered newest first.PaymentSourceThe source of the payment. This is used to identify the integration and specific connection that facilitated the payment within the integration.PaymentStatusPhoneE.164 formatted phone number. Ex. +14155554345RecurringProcessingModelHow a stored payment method may be used for a later payment, following the card networks' stored-credential framework. The model is declared when a method is stored and again on every payment made from it, and it decides how that later payment is treated for Strong Customer Authentication: a Subscription or UnscheduledCardOnFile charge is one you initiate and falls outside SCA, while a CardOnFile charge does not. What separates the two models you initiate is the schedule, not the amount. A run of payments on a fixed interval is a Subscription even when the amount differs every time.StorePaymentMethodModeWhether a payment session stores the payment method the customer enters against its contact, and whether the customer gets a say in it.StorePaymentMethodResultWhat became of a payment session's request to store the payment method, once the session completed.URLA URL with protocol and port. ex. https://example.comVaultBankAccountHolderTypeWhether a bank account belongs to a person or a business.VaultTokenA card or bank account held in the ClientLoop vault, referenced by an opaque token. A third party tokenizes an instrument once with 'vaultTokenizeCard' or 'vaultTokenizeBankAccount' and presents the token later in place of the account data. A token is short-lived until it is used: one not used to create a payment or payment plan within an hour of being created is deleted, together with the instrument it holds. A token that has been used lives as long as the payment or plan needs it. A vault token is not a stored payment method. It is optionally attached to an organization and to a contact, and carries no consent or recurring arrangement of its own; keeping an instrument on file for a contact is what 'PaymentMethod' is for. The account number itself is never returned: a token exposes the BIN, last four digits, expiration and brand of a card, or the routing number and last four digits of a bank account.VaultTokenBankAccountBank account detail for a vault token whose type is BankAccount.VaultTokenCardCard detail for a vault token whose type is Card.VaultTokenConnectionA page of vault tokens following the [Relay Connection spec](https://relay.dev/graphql/connections.htm). edges holds the tokens in this page (each with its cursor) and pageInfo describes whether more pages exist in each direction plus the cursors that bound this page.VaultTokenEdgeA single element of a VaultTokenConnection page: the token itself (node) plus the opaque cursor that points at it. Pass a cursor back as 'after' (forward) or 'before' (backward) to page relative to this row.VaultTokenStatusWhether the instrument behind a vault token is still current, judged each time it is read. Deletion is separate and told apart by 'deletedAt': a deleted token still reports a status, and can still move to Expired, so a token is usable only while its status is Active and it has not been deleted.VaultTokenTypeThe kind of instrument a vault token stands for.