Skip to main content
Repeat Recipient lets a returning recipient confirm an account they have already used instead of entering their details again. Ingo associates saved accounts to the customer identifier you send when you stage the payment, so the next time that same recipient is paid, they can accept the payment in fewer steps. The mechanism is the same for Notify — Classic and Notify — Managed Parties: you send a stable identifier for the recipient, Ingo retains successfully used accounts against it, and the recipient confirms or chooses at payment time.
Repeat Recipient is a program-level configuration, not a per-recipient setting. Ingo enables it for your program and it then applies to every recipient you send an identifier for. Confirm whether it is enabled on your configuration with your Integration Manager.

​
How it works

1

You send a customer identifier

Include your identifier for the recipient when you stage the payment. This value is what saved accounts are associated to, so it must be stable for that recipient across payments.
2

The recipient enrolls an account and gets paid

The recipient enters their account details and the payment completes successfully. At that point the account is retained against your identifier.
3

The next payment reuses the account

On a subsequent payment under the same identifier, the recipient confirms the saved account rather than re-entering it. No new tokenization is required.
4

Multiple saved accounts present a selection list

If more than one account has been saved for that identifier, the recipient is presented a list and selects which one to use for this payment.

​
Which disbursement types can be saved

Repeat Recipient is not limited to cards or bank accounts. Any disbursement type enabled on your configuration can be saved and reused, including debit card, ACH, RTP-eligible accounts, and PayPal. A recipient’s saved list can contain a mix of types. When more than one account is saved, the selection list presents all of them together and the recipient chooses one for that payment — for example, a debit card and a PayPal account side by side.
Which types appear for your recipients depends on the disbursement options enabled for your program. Confirm your enabled payment methods with your Integration Manager, and see Payment Methods for the full catalog.

​
The identifier that scopes saved accounts

Saved accounts are associated to the customer identifier you send — not to the recipient’s name, email, or phone number. The field depends on your integration:
In Notify — Managed Parties, disbursement-only recurring notifications (notify_type: 2) route on the party_id returned from a prior enrollment rather than client_provided_id. See Notification Types.
Send the same identifier for the same person every time. If the value changes between payments, Ingo treats the recipient as new and they will enroll an account again. If the same value is sent for two different people, they share a saved account list.

​
When an account is saved

Entering an account does not save it. An account is retained against your identifier only after both of the following:
  1. The account is successfully enrolled and tokenized, and
  2. A payment to that account completes successfully.
This is why a recipient’s list contains only the accounts they have actually been paid to. Accounts entered during an attempt that did not result in a successful payment — an abandoned session, a failed verification, a declined disbursement — are not added to the list.
If a recipient reports seeing fewer accounts than they expect, the likely reason is that the missing account was entered but never used for a completed payment.

​
Account lifecycle and removal

Once an account is saved it remains associated to your identifier.
There is no removal function for a saved account. A recipient cannot delete an account from their own list, and there is no administrative function for Ingo to remove one on request.The only circumstance in which a saved account is dropped is an unrecoverable processing error on that specific account.
An account that is no longer usable — an expired or replaced card, a closed bank account, a deactivated PayPal account — stays visible in the recipient’s list. It is only used if the recipient selects it, and selecting it does not affect any other saved account.

​
Giving a recipient a clean list

To present a recipient with a clean list, send a new customer identifier value for that recipient on their next payment. Ingo treats the new value as a new customer record, so no previously saved accounts are associated to it. The recipient enters the account they want to use once, and it is retained for future payments under the new value.
1

Generate a new identifier value for that recipient

The value must be new to your program — not one you have used for this or any other recipient.
2

Send it on the next payment

Populate the new value in the identifier field for your integration. No configuration change or development work is required on Ingo’s side.
3

The recipient enrolls once more

The recipient enters their account and, once that payment completes successfully, it is saved against the new value.
This associates the recipient with a new customer record going forward. It does not delete their previously saved accounts — those accounts remain associated to the old identifier value and are simply no longer surfaced. Payment history and reporting tied to the previous value are unaffected.
A new identifier does not reset velocity limits. Transactional velocity limits accumulate against the destination account itself — identified by account_id — not against the customer record. Sending a new customer identifier gives the recipient a clean list of saved accounts, but any cumulative daily or rolling-window totals already counted for the account they select still apply. See Transactional Velocity Limits.
Consider your own system of record first. If your customer identifier is derived from an ID in your own systems — a member, claim, participant, or account number — changing it for one recipient may affect your internal tracking, reconciliation, or reporting. Decide how you want to generate the new value so it remains meaningful on your side before you send it.

​
Common questions

Yes. Multiple accounts can be saved against a single customer identifier, and they can be of different disbursement types — a debit card, an ACH account, and a PayPal account can all be saved for the same recipient. When more than one is saved, the recipient selects which to use at payment time.
No. There is no self-service removal for the recipient and no administrative removal function. To present a clean list, send a new customer identifier value for that recipient.
They should not. An account is saved only after a payment to it completes successfully, so anything in the list has been paid to at least once under that identifier.
That payment attempt fails on the selected account and the recipient can choose another saved account or enter a new one. Other saved accounts are unaffected.
No. Velocity limits accumulate against the destination account rather than the customer record, so a new identifier clears the saved account list but not any cumulative totals already counted for the account the recipient selects.
No. It is a program-level configuration and applies to all recipients you send an identifier for. Disabling it would require every recipient to enroll an account on every payment.

​
Prerequisites

  • Repeat Recipient enabled on your Notify configuration by Ingo.
  • A stable customer identifier for each recipient, unique within your program.
  • You are already live or in-flight on Notify — Classic or Notify — Managed Parties. Repeat Recipient is a feature add, not a standalone integration.

​
Testing

During UAT, validate the behavior end to end: stage a first payment and complete it so an account is saved, then stage a second payment under the same identifier and confirm the recipient can reuse the account without re-entering details. Save a second account and confirm the selection list appears. Then stage a payment under a new identifier value and confirm the recipient starts with a clean list. See the Repeat Recipient scenarios in Notify — Classic testing and Notify — Managed Parties testing.