Skip to main content
Understanding why a card was challenged or refused is the difference between resolving a support ticket in minutes and escalating it for a week. Four layers feed the outcome:

​
What Triggers Each Path

Red — declined outright
  • The PAN, expiration, and CVV do not match a card
  • The card is not active, or is reported expired, lost, or stolen
  • The cardholder is not in an active state
  • More than five provisioning attempts with an incorrect CVV in the last 24 hours
  • The wallet provider returns its lowest device trust score
  • The card product is not configured for this provisioning method
  • Network provisioning rules decline the attempt
Yellow — step-up required
  • The wallet provider recommends additional verification
  • The network recommends additional verification under a rule configured for your BIN
  • Address verification is enabled for the method and the supplied address does not match the one on file
Green — approved Neither red nor yellow was triggered.
The wallet providers’ risk models are proprietary and not configurable. They weigh device history, how long the wallet account has existed and how much it has transacted, the device’s location against the cardholder’s address on file, whether the device was recently reset or reported lost, and bursts of provisioning activity across cards or devices.

​
Step-Up Verification

On the yellow path the cardholder must prove they are who they claim before the token activates. The cardholder does this through SMS or Email OTP (one-time passcode). Because OTP delivery depends on contact details, every cardholder needs both a mobile number and an email address on file. Collect them during onboarding — a cardholder without them cannot complete a yellow-path challenge, and the token will eventually be refused.

​
Address Verification

Address verification can be enabled per provisioning method on the card product, checking the address supplied during provisioning against the one on file. A mismatch sends the attempt to the yellow path rather than declining it. It is optional, and it trades friction for fraud protection. Programs whose cardholders move often, or whose address data is incomplete, see more step-up challenges with it on.

​
Why Provisioning Fails

When a cardholder cannot add their card, the decline reason is visible on the token in the Synctera console. The common ones:
Issuing a new card rarely fixes a provisioning decline. Most reasons describe the device or the wallet account, not the card — so a replacement card presented from the same device scores the same way. Check the reason first.
Where a decline is wrong — a known-good cardholder on a distrusted device — the device can be allow-listed with the wallet provider. Raise it with Synctera support with the token ID and the decline reason. Allow-listing goes through the wallet provider and can take up to 24 hours to take effect after it is applied.

​
Troubleshooting

When escalating to Synctera support, include the token ID, the decline reason, and the device from the token. Without those the request cannot be taken to the wallet provider.

​
Next Steps

Token Lifecycle Management

Managing tokens that were provisioned successfully.

Tokenization Overview

How tokenization works and what your program needs.