DEVELOPER PLATFORM
Account Updater API
Account Updater keeps stored cards current so repeat billing survives an expiry or a reissue. Cards get replaced constantly, and none of that is a decision to stop paying a business, yet each replacement becomes a declined renewal that looks exactly like churn. The RapidCents API checks enrolled credentials against network updates and applies new numbers and expiry dates to the stored token, with no change to billing code and no contact with the customer. Credentials that cannot be refreshed are flagged instead.
- Sandbox with documented test cards
- Signed webhooks
- Typed errors and idempotent retries
- Dedicated developer support
What crosses the wire
Where it sits
Behind the token, not in front of the charge. Your systems keep referencing the same token; what changes underneath is the credential it resolves to. Nothing in your billing code has to know an update happened.
What you enrol
Stored payment methods you bill repeatedly. Enrolment is the deliberate step: a token that is never enrolled is never refreshed, and that is the most common reason an updater appears not to be working.
What comes back
Two outcomes worth handling differently. A refreshed credential, applied automatically and reported so you can see which methods changed and when; and an exception, flagged because it could not be refreshed and needs the customer.
When to use it
Subscriptions and memberships
Any book of recurring revenue needs stored cards kept current. This is the tool that refreshes those credentials so memberships and plans keep collecting.
Instalment plans
A plan that breaks in month seven is worse than one that never started, because the customer has to be contacted mid-commitment about something they did not do.
Card-on-file commerce
One-click checkout depends on the stored card still working. RapidCents refreshes the credential so a returning customer can complete the sale on the method they already saved.
How to implement Account Updater API
Enrol the stored methods you bill on a schedule, not every token you hold.
Let refreshed credentials apply to the token automatically, with no change in your billing code.
Read the update report to see which methods changed, and when.
Route flagged exceptions into an outreach flow before the next scheduled charge.
Measure recovered renewals so the enrolment is justified by what it actually saved.
What fails, and how you find out
Expecting universal coverage
Refresh depends on the card network and the issuer participating in update services. Some credentials will never be refreshed, and an integration that assumes otherwise has no plan for the ones that are not.
Ignoring the exception list
The flagged methods are the ones that need a human. Leaving them to fail on the next cycle wastes the warning the updater gave you and turns an avoidable decline into a support call.
Storing a copy of the card details
If your systems hold their own copy of the expiry date, it goes stale while the token stays current, and your validation starts rejecting a card that would have worked.
Treating it as a substitute for dunning
It removes a cause of failed renewals; it does not remove failed renewals. Insufficient funds, blocks and closed accounts still need a retry policy and a way to reach the customer.
Sandbox versus production
The mechanism is testable, the coverage is not
Sandbox can show a refreshed credential flowing through to a stored token and a renewal succeeding on it. What it cannot tell you is how often that will happen on your own book of business.
Exercise the exception path deliberately
The branch that matters most is the one where a card could not be refreshed. Force it in sandbox and confirm your outreach flow actually fires, because in production it fires quietly and only sometimes.
Enrolment is environment-scoped
Tokens do not cross environments, so enrolment done in sandbox proves your integration and has no effect on production. The production enrolment is a separate, deliberate step.
Questions about Account Updater API
Which cards can be refreshed?
Coverage depends on the card network and the issuer participating in update services. It is genuinely partial rather than universal, which is why the flagged-exception path is part of the design rather than an afterthought.
Does the customer have to do anything?
No. Updates apply to the stored token in the background, with no notification and no re-entry, which is the entire point: the customer never learns that their renewal was about to fail.
What if a card cannot be refreshed?
It is flagged so you can ask the customer for a new method before the next charge. Acting on that list ahead of the billing date is what turns a decline into a routine update.
Does my billing code change when a credential is updated?
No. You keep charging the same token; only the credential behind it changes. That is why enrolment is worth doing early — the integration work is enrolment and exception handling, not billing.
Is this the same thing as retrying a failed payment?
No, and they solve different problems. Retries attempt the same credential again in the hope the reason was temporary. The updater changes the credential, which is the only thing that helps when the card itself was replaced.
Should every stored card be enrolled?
Enrol what you bill on a schedule. A card stored for a one-off convenience gains little, and narrowing enrolment to the recurring book keeps the exception list short enough that someone actually works it.
Why does the updater look like it is doing nothing?
Usually because the tokens were never enrolled. Enrolment is the deliberate step, and a stored method that is not enrolled is never refreshed, which is the most common reason the service appears inactive. Enrolment is also environment-scoped, so doing it in sandbox proves the integration and has no effect on production.
Should my own database keep the card expiry date?
No. Keep the token and, for display, the brand and last four digits. A copy of the expiry date held in your systems goes stale while the token behind it stays current, and your own validation then starts rejecting a card that would have been approved.
Continue the integration
A RapidCents subscription charge created over the API, using the same billing engine as the dashboard. Recurring Payments API
Build subscriptions, installments and retry logic against the same billing engine used by the…
ExploreThe RapidCents tokenization API returning a card token, so merchant software never stores the PAN. Tokenization API
Create, reuse and retire payment tokens programmatically so your systems never store card…
ExploreA RapidCents API request and its response on a developer workstation, with the merchant dashboard and a test terminal. RapidCents APIs
REST APIs for payments, refunds, customers, tokens and settlement, with predictable errors and…
ExploreA typed RapidCents API error on screen, next to the declined sandbox terminal sale that produced it. Errors
Typed error codes, retry guidance and idempotency patterns for production reliability.
Explore
Take the next step
Talk to a RapidCents specialist
RapidCents Fee Check reads a processing statement and shows interchange separately from the markup. Upload a statement for an instant breakdown, or open a merchant account and start accepting payments on one account.
- No obligation
- Payment specialists, not a call centre
- Secure statement upload
