Support
Testing Considerations
Some APIs depend on external configuration, wallet provider setup, tokenization readiness, fraud event generation, or live BIN/program conditions.
These APIs may be visible in the API catalog, but full end-to-end testing in UAT may be limited until the required dependencies are enabled.
Overview
API catalog visibility does not always mean every flow can be fully tested end to end in the current UAT environment. Some endpoints require provider configuration, wallet setup, tokenized data, fraud event generation, or supported program setup before the complete lifecycle can be validated.
Use this page to identify APIs that may require additional configuration before full testing is possible, and to separate partial API contract testing from complete end-to-end validation.
External configuration
Some APIs require processor, network, wallet provider, 3DS provider, fraud provider, or program-level configuration before full end-to-end testing is possible.
Program readiness
Some flows depend on BIN, program, card, token, wallet, or supported UAT scenario readiness before they can be fully validated.
Visible but limited
Some APIs may be visible in the API catalog even when full end-to-end testing is limited because required dependencies are not yet active.
Test in phases
Validate request shape, authentication, and response behavior first. Complete full lifecycle testing after dependencies are enabled.
Testing dependency model
When an API depends on external readiness, use a phased testing approach instead of blocking all validation work. This allows the implementation team to test authentication, request structure, and response handling while waiting for provider or program dependencies.
Contract testing
Validate endpoint access, required fields, request shape, authentication, and expected response structure.
Dependency waiting
Track missing provider, network, wallet, fraud, BIN, or program setup as a testing blocker.
End-to-end testing
Complete full lifecycle validation once the required configuration and supported test scenarios are available.
Wallet
Digital Wallet Provisioning / In-App Provisioning
APIs included
- Apple In-App Push Provisioning
- Google In-App Push Provisioning
- Apple In-App Push Provisioning Verification
- Google In-App Push Provisioning Verification
Testing limitation
These flows depend on wallet provider configuration, token requestor data, token service provider readiness, and BIN/program setup. In-app provisioning also requires the mobile app and server-side integration to pass encrypted provisioning data to Apple or Google wallet flows.
Testing recommendation
Confirm API authentication, request format, and required fields first. Complete full wallet provisioning validation after wallet provider configuration and BIN/program setup are active.
Tokens
Card Tokenization
APIs included
- Get Card Payment Tokens
- Get Card Payment Token Devices
- Unbind Payment Token
- Update Payment Token Status
- Update Payment Token Status — Idempotent
Testing limitation
These APIs depend on tokenized cards or payment tokens already existing in the environment. Without active wallet tokenization events, full lifecycle testing is limited. Therefore, these endpoints also depend on Digital Wallet configuration.
Testing recommendation
Validate endpoint access and response handling where possible. Complete full lifecycle testing after wallet tokenization events and payment tokens exist in the environment.
Authentication
3D Secure Enrollment
APIs included
- Create 3DS Credentials
- List 3DS Credentials
- Update 3DS Credentials
- Update 3DS Credential — Idempotent
- Delete 3DS Credentials
- Get 3DS Configuration Details
Testing limitation
Full validation depends on 3DS provider setup, authentication method configuration, card/program readiness, and supported UAT scenarios. Required configuration is currently being completed by provider.
Testing recommendation
Validate credential endpoint request/response behavior first. Complete full delegated authentication and challenge testing once 3DS provider setup and supported UAT scenarios are ready.
Checkout
Click to Pay
APIs included
- Enroll Data
- Get Payment Instrument Information
- Enroll Payment Instruments
- Manage Payment Instrument
- Manage Consumer Information
- Delete Consumer Information
- Delete Payment Instrument
- Retrieve Consumer and Payment Instruments Information
Testing limitation
These APIs depend on network/payment credential configuration and supported program setup. Full testing can only be completed once Click to Pay configuration is active for the program.
Testing recommendation
Confirm request structure, required identifiers, and expected responses first. Complete full enrollment, retrieval, update, and delete testing after Click to Pay configuration is active for the program.
Fraud
Fraud Alerts & Fraud Event Handling
APIs included
- Record Fraud Login Event
- Submit Fraud Alert Response
Testing limitation
Full validation depends on fraud monitoring configuration, fraud rules being enabled, fraud alert/event generation, webhook or event subscription setup, and supported test scenarios that can trigger fraud-related events. Required configuration is currently being completed by provider.
Testing recommendation
Validate endpoint availability and request behavior first. Complete full fraud alert lifecycle testing once fraud monitoring, rules, event generation, and webhook/event subscriptions are configured.
Recommended testing approach
Use this sequence when testing APIs that may have external or program-level dependencies.
Confirm visibility
Confirm the API is visible in the API catalog and that the target environment is correct.
Validate authentication
Confirm the access token, scope, subscription, and headers are valid for the selected environment.
Validate request shape
Validate required fields, path parameters, body structure, and expected response format.
Confirm dependencies
Confirm whether external provider, network, wallet, 3DS, fraud, BIN, or program setup is required.
Perform partial testing
Where full testing is blocked, complete the parts that can be validated without the missing dependency.
Complete end-to-end testing
Complete full lifecycle testing after the required configuration and supporting scenarios are enabled.
Implementation notes
Use the following notes when planning UAT, test evidence, implementation tracking, or go-live readiness.
- Do not assume an API is fully testable just because it is visible in the API catalog.
- Document which dependencies must be enabled before end-to-end testing can be completed.
- Separate API contract testing from full lifecycle testing when provider or program setup is not ready.
- Capture request IDs, timestamps, card identifiers, publicToken values, program details, and environment details during testing.
- Use idempotent endpoints where available when retrying update operations.
- Confirm whether the limitation is caused by configuration, test data, provider readiness, or unsupported UAT scenarios.
- For blocked tests, record the expected blocker and retest once the dependency is enabled.
If full UAT validation is blocked, record the blocker, the dependency owner, the affected API, and the specific test scenario that cannot be completed yet.
Next steps
After reviewing API availability and testing considerations, return to troubleshooting guidance if a specific request, response, webhook, or environment issue needs to be investigated.