# Testing transactions that use custom link tokens Recognize custom link tokens that your app receives in the sandbox testing environment, and use them to test reporting transactions. ## Overview When you test your app in the sandbox environment, the External Purchase API returns tokens that are valid only in that environment. These tokens have an that starts with the string `SANDBOX`. For more information about the token format, see [Receiving and decoding external purchase tokens](/documentation/StoreKit/receiving-and-decoding-external-purchase-tokens). Apps running in the sandbox environment need to satisfy the same requirements as they do in the production environment to receive external purchase tokens, including that they: - Have an entitlement, such as or - Configure the associated property list key if the entitlement requires one, such as or - Check their eligibility to use the [External Purchase](/documentation/StoreKit/external-purchase) API at runtime, with [`isEligible`](/documentation/StoreKit/ExternalPurchaseCustomLink/isEligible) and [`canMakePayments`](/documentation/StoreKit/AppStore/canMakePayments) ### Handle custom link tokens in the sandbox environment The [`ExternalPurchaseCustomLink`](/documentation/StoreKit/ExternalPurchaseCustomLink) API generates custom link tokens, which have a token type and an expiration date. There are two possible token types, `ACQUISITION` and `SERVICES`. Your app requests a token by calling the `ExternalPurchaseCustomLink/token(for:)` method and specifying the token type. The first time you request a token in the sandbox environment, the system creates the token and initiates an *active token period*. > Note: In the sandbox environment, custom link tokens expire 1 hour after creation. Apps can request tokens again at any time. If there’s an active token period, the system returns the token that corresponds to that active period. The returned token can be identical to the original token, or it can be a *refreshed* token. A refreshed token has the same creation and expiration dates as the original token, but a different `externalPurchaseId`. Use either an original token or a refreshed token to report transactions. There’s a maximum of one active token period for `ACQUISITION` tokens, for each Sandbox Apple Account, for each app. After the `ACQUISITION` token expires, the Sandbox Apple Account can’t receive another `ACQUISITION` token for the same app. This reflects the behavior in the production environment, where apps have a maximum of one active period for the `ACQUISITION` token for each customer. To repeat tests for this token type after it expires, use another Sandbox Apple Account. After a `SERVICES` token period expires, your app can request a new `SERVICES` token and you can continue testing. The new token has a new creation and expiration date, and starts a new active token period. ### Test reporting tokens on your server To test your server’s token reporting implementation, send reports for sandbox tokens to the Sandbox URL of the [Send External Purchase Report](doc://com.apple.documentation/documentation/ExternalPurchaseServerAPI/Send-External-Purchase-Report) endpoint. For more information about reporting tokens, see [External Purchase Server API](doc://com.apple.documentation/documentation/ExternalPurchaseServerAPI). To report transactions, you can use any token for the customer that’s active (not expired) at the time of the transaction. --- Copyright © 2026 Apple Inc. All rights reserved. | [Terms of Use](https://www.apple.com/legal/internet-services/terms/site.html) | [Privacy Policy](https://www.apple.com/privacy/privacy-policy)