iOS

Unable to add card using Sandbox

There are a few possibilities on why the error occurs:

• The device is logged in without using the Sandbox iCloud account.

• The PAN that is being used is not the Sandbox PAN. See Apple Sandbox Testing for more information.

D1 SDK cardDigitizationState API still returns notDigitized after the card provisioning process

The possibilities for this error are:

• Production testing shall be performed in the Production using production devices via Ad-hoc Provisioning Profiles, TestFlight or the production App Store by means of Promo Codes, after the necessary approvals.

• The provisioning profile does not have the correct entitlements. Refer to this page to set up the entitlements.

• It may be due to the setting of your issuer application details on the payment network system (for Visa and Mastercard). As per Apple specification, the issuer needs to configure their issuer application details in the payment network portal system in the following format:

  • associatedApplicationIdentifiers: TeamId.BundleId

  • associatedStoreIdentifier: AdamId

  • appLaunchUrl: Your application's URL.

The following figure shows an example on where to add Application Identifiers/ADAM ID and Application URL on Mastercard.

Example: payment network portal configuration fields (Mastercard)

Card not added before T&Cs

Example: card not added before T&Cs

How to diagnose

Enter the SEID of the device in the Search bar located in the top right hand corner.

This will output a set of logs with requests and responses, looking through the log output, the issuer can select the request message, as shown in below figure, where the highlighted field displays an output specific to the chosen message.

For this use case, the information that can be validated in the request is the encryptedPassData and the ephemeralPublicKey, as this is the data that is sent from the device to the server.

In below figure, the issuer can view the the log archive request / response.

Below the log archive, the response from the server is displayed in a more readable format, with the error code highlighted.

The response yields an error 500 which is a generic error, and reasons to resolve are listed in the resolution section.

Response: ...[Other data not logged here]
{
   ...[Other data not logged here]
}
{
   statusCode = 500;
   statusMessage = "Broker Service Response exception”;
}

Example: log archive details with error highlighted

There are multiple reasons why the issuer may receive this error:

• Cryptography error, wrong data encoding, or invalid JSON dictionary.

  This could be resolved with use the cryptography implementation and validation pages to resolve any issues with the issuer’s cryptography or data format.

• Whitelisting (Incorrect Adam ID is whitelisted)

  This applies only for tests done in Production.

  • Has the issuer requested the whitelisting of their app’s Adam ID?

  • If yes, is the issuer distributing their app via TestFlight? For TestFlight, the minimum supported build must set to iOS 10.3. When the issuer does eventually build the app for the production App Store, the issuer may move the minimum supported iOS version back to iOS 9.0 or later.

• Issue with the resources such as T&Cs and Card Art being loaded.

  This is highly unlikely to be error. It may typically happen in PreProd where the configuration on the payment network portal may be subject to frequent changes. To exclude this error try to add the card manually via Apple Pay wallet. If the issuer sees the T&Cs while adding the card manually they can rule out this problem. If the manual provisioning fails, the issuer should contact their respective payment network portal, and attempt to re-upload their T&Cs to the payment network portal.

Ineligible card

Example: ineligible card

As opposed to Card Not Added’ Before T&Cs scenario, in this case the server responds with a status code 200, which means the request completed successfully.

However, by looking at the response the issuer can see that the server returned the card as non eligible (i.e. eligibilityStatus= 0).

{
   "Content-Length" = 57;
   "Content-Type" = "application/json";
   Date = "Tue, 21 May 2019 04:40:57 GMT”;
   "x-conversation-id" = 086063f209b34b84bee028a75c6af0f2;
   ...[Other data not logged here]
} 
{
   errorCode = 40403;
   ...[Other data not logged here]
}

This issue is caused when the card details provided are not eligible for Apple Pay (for example, card not whitelisted by the payment network or the issuer).

The issuer should check with the payment network that the card has been correctly configured.

Issuer declines provisioning: Red flow response

Example: Red flow response

A failure after the end user has accepted T&Cs is often related to a decline on the issuer side.

The declined is represented by a Red Response.

This could be caused by several factors.

For example, it may be the issuer declining the attempt or it may be the payment network responding on behalf of the issuer is the response takes too long to be processed.

By looking at the logs for this type of error the issuer can see that they have an error code which has returned 40403, where the device would display: “Could not add Card, Try again later or contact your issuer for more information”.

{
   "Content-Length" = 57;
   "Content-Type" = "application/json";
   Date = "Tue, 21 May 2019 04:40:57 GMT”;
   "x-conversation-id" = 086063f209b34b84bee028a75c6af0f2;
   ...[Other data not logged here]
} 
{
   errorCode = 40403;
   ...[Other data not logged here]
}

Red flow is the response provided from the issuer, in this event, they should contact the payment network, with the ‘conversationID’.

Using this the payment network should be able to identify the underlying reason for the response.

Unknown card type

This is due to an incorrect bundle identifier.

To fix this, Apple recommends to change the bundle identifier.

An example of the error is shown as follows:

PassbookUIService         AMSCardEnrollmentEligibilityTask: [D72FE7E2] Attempting to determine card type for passTypeIdentifier: paymentpass.com.apple, serialNumber: nc.prod.cert_5395c9ae24b346e7ad08fcca25a46912

PassbookUIService         tcp_input [C127.1:3] flags=[F.] seq=1370165038, ack=1840204742, win=502 state=CLOSED rcv_nxt=1370165014, snd_una=1840204718

PassbookUIService         AMSCardEnrollmentEligibilityTask: [D72FE7E2] Card is unknown type of PKPaymentPass

PassbookUIService         PKNotifyCoalescer: unregistered for notification com.apple.NPKCompanionAgent.listener.resumed.

PassbookUIService         {public}<private>:0x282608f30 (0x282530a00): Tearing down existing connection

PassbookUIService         AMSCardEnrollmentEligibilityTask: [D72FE7E2] Found card type: 0

PassbookUIService         AMSURLRequestEncoder: [D72FE7E2] Encoding request for URL: https://p19-buy.itunes.apple.com/account/stackable/applePay/silentEnroll/eligible {

                account = <ACAccount: 0x282d2e5a0 type = iTunesStore | backingID = BE105BB6-8208-4E56-AEA9-8615DE4C093F | username = [e-mail] | altDSID = 000014-10-8f1f9b5d-1c5e-4f41-b9e4-85ee3dc81e11 | DSID = 20100559835 | active = true | storefront = 143441-1,29>

                mediaType = com.apple.AppleMediaServices.accountmediatype.production

Push provisioning returns status code 1

• PreProd: The testing is not triggered with an Apple sandbox testing account. Refer to Apple Sandbox Testing page on how to do sandbox testing.

• Production: The application is not published to the App Store, which causes Apple to restrict it.

An example of the error is shown as follows:

L_Stage[866:312743] [TPCSDK] ProvisionViewController addPaymentPassViewController: ephemeralPublicKey: BNEz67GTNp2YEtS/hkUDaMJh/zGjBVFbMMIYu5E4xsMoCgeCsR8Qy8A/YGnmXDCZVBpAzmhdrD+e3WpFswdU7e8=

2021-03-26 18:49:21.422819+0300 UCFS_TAS_HEEL_Stage[866:312743] [TPCSDK] ProvisionViewController addPaymentPassViewController: Create request

2021-03-26 18:49:32.050545+0300 UCFS_TAS_HEEL_Stage[866:312743] [TPCSDK] ProvisionViewController addPaymentPassViewController:didFinishAdding BEGIN

2021-03-26 18:49:32.056856+0300 UCFS_TAS_HEEL_Stage[866:311885] [TPCSDK] ProvisionViewController addPaymentPassViewController:didFinishAdding error: The operation couldn't be completed. (PKPassKitErrorDomain error 1.)

The flow is correctly initiated for Thales but Mastercard does not receive the push.

In device logs the error

Push provisioning returns status code 403

This error occurs because the push provisioning flow is rejected by the issuer backend but is successful (red flow).

The details of the error is shown as follows:

[PassbookUIService error] Received Status Code 403.

Push provisioning returns 500

This error occurs because that Apple sandbox test account is not configured on the testing device.

An example of the error is as follows:

{ 
  "Content-Length" = 49; 
  "Content-Type" = "application/json"; 
  Date = "Fri, 21 May 2021 14:06:16 GMT"; 
  Vary = "accept-language"; 
  "x-conversation-id" = 8a7e25b542b34cc9a4077fb411c1b2eb;
  "x-envoy-upstream-service-time" = 625; 
  "x-pod" = "crt-pod1"; 
  "x-pod-region" = "paymentpass.com.apple"; 
} 
{ 
  errorCode = 40456; 
  statusCode = 500; 
}