Test Card Numbers and Scenarios

The following are sample cards to facilitate endpoint testing. When provisioning these cards, the exact combination of PAN, expiry (month and year), and account input method must match the provided table. If any of those details do not match, the response will be an invalid request error with an invalid_card_data message.

When calling the /notifications endpoint, the state of the token is not saved in the Sandbox. Calls to the /notifications endpoint will return the response that would be received when calling it from outside the Sandbox. To preserve the integrity of the Sandbox calls, tokens will not be cancelled when a delete request is sent to the /notifications endpoint. This approach is necessary to ensure that the Sandbox data is guaranteed to be resilient against service interruptions.

Because the state of the token is not changed in the Sandbox, the /status endpoint will return Active for any tokens provisioned in the Sandbox for scenarios 1, 2, 3, and 4. Additionally, the /metadata endpoint will always return the meta-data for the token reference ID produced by any of these aforementioned scenarios because the token is active in the system. Furthermore, any calls to the /notifications endpoint will return a 200 OK response.

The Card used in Scenario 3 is mapped to the country of India. Because the Card is Indian, attempts to provision the Card will only succeed if the authentication_method field under the /provisionings endpoint specification is provided. Attempts to provision the Card on the /purchasetokens endpoint will not succeed as the authentication_method field is not supported for that endpoint. The value to provide in the value field within the authentication_method JSON object is BwACAkYlhgICEwADMTE2EAAAAAA=.

The token provisioned as part of Scenario 5 will be cancelled immediately. As such, calls to the /status endpoint for a token reference ID produced by Scenario 4 will return a status of Cancelled. Calls to the /metadata endpoint will return an invalid_token_ref_id response as inactive tokens will return such an error when /metadata is called. Attempts to delete the token on the /notifications endpoint for the deleted token will return a 200 OK response. Multiple calls to delete the same token will produce an idempotent response from the system. Attempts to resume or suspend the token which has already been cancelled will return a 401 Unauthorized error indicating that the caller is not authorized to perform the operation. Once a token has been cancelled, it cannot be restored.

The token provisioned as part of Scenario 6 will be suspended immediately. As such, calls to the /status endpoint for a token reference ID produced by Scenario 5 will return a status of Suspended. Calls to the /metadata endpoint will return an invalid_token_ref_id response as suspended tokens will return such an error when /metadata is called.

Number Scenario PAN Expiry Account Input Method 1 Tokenizing a valid Card 37111 11111 11114 12/2030 "User Input" 2 Tokenizing an outdated Card 37111 11111 11122 12/2019 "On File" 3 Tokenizing a Card from India 37111 11111 11161 11/2030 "User Input" 4 Tokenizing a valid Card to test meta-data notifications 37111 11111 11130 12/2030 5 Tokenizing a valid Card to test deleted token notifications 37111 11111 11148 12/2030 6 Tokenizing a valid Card to test suspended token notifications 37029 50806 73971 12/2030 "User Input" 7 Card cannot be tokenized error 37000 00000 00002 12/2035 8 Card not eligible error 37000 00000 00028 12/2035 9 Card market not supported error 37000 00000 00036 12/2035 10 Issuer not supported error 37000 00000 00044 12/2035 11 Card cancelled error 37000 00000 00051 12/2035

Outbound Notifications On Token State Updates

In some scenarios, American Express will send an outbound notification to the Merchant who provisioned the token. If the state of the token is changed by AMEX, an outbound notification will be triggered to the Merchant. This outbound notification behavior is tested in scenarios 4 & 5 above. To execute these test scenarios you must contact your American Express representative and specify the endpoint to which outbound notifications should be directed. This information needs to include SSL Certificates, URLs, and all IP addresses. Any header requirements for incoming calls to the Merchant’s specified endpoint will be stored and respected by outbound calls from AMEX to the Merchant’s desired endpoint.