[IAPKit][FR] Read-only order lookup by Apple or Google order ID

[LukasB-DEV]

Hi @hyochan, Would it be possible to add a read-only order lookup to IAPKit using the store credentials and app identifiers already configured for verification?
When a user contacts support, they usually provide the receipt from Apple or Google, which includes the order number. To quickly obtain more information, the corresponding lookup provided by Apple and Google would be useful here.

Workflow

1. Select Apple App Store or Google Play
2. Enter an order ID
3. Click Look up order
4. Display the complete order and subscription information

Apple

Use the App Store Server API:

GET https://api.storekit.apple.com/inApps/v1/lookup/{orderId}

The JWT can be generated using the existing Apple credentials and Bundle ID.

Decode the payloads from signedTransactions and display available fields such as:

• Product ID and product type
• Transaction ID
• Original Transaction ID
• Web Order Line Item ID
• App Transaction ID
• Purchase and original purchase dates
• Expiration date
• Revocation date and reason
• Environment
• Storefront
• Quantity
• Price and currency
• Transaction reason
• Ownership type
• Offer information
• Subscription Group Identifier
• App Account Token
• Upgrade status

Apple Order Lookup should be described as supporting real App Store orders, not sandbox order numbers.

Optional Apple subscription status

If an originalTransactionId is available, additionally request:

GET https://api.storekit.apple.com/inApps/v1/subscriptions/{originalTransactionId}

Display:

• Current subscription status
• Expiration date
• Auto-renew status
• Renewal Product ID
• Grace-period expiration
• Billing retry status
• Expiration intent
• Cancellation or non-renewal
• Revocation or refund status

Failure of this optional request should not invalidate a successful order lookup.

Google Play

Use the Google Play Developer API:

GET https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}

Display available fields such as:

• Order ID and order state
• Sales channel
• Creation and last-event times
• Buyer country and region
• Total amount
• Tax
• Developer revenue
• Currency
• Product title and Product ID
• Listing price and total
• Product type
• Service-period start and end
• Offer phase
• Free trial
• Introductory price
• Base price
• Proration details
• Processing, cancellation and refund events
• Partial refunds

The Purchase Token should be masked by default, with separate Show and Copy actions.

Optional Google subscription status

For subscription orders with a Purchase Token, additionally request:

GET https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/purchases/subscriptionsv2/tokens/{purchaseToken}

Display:

• Subscription state
• Latest order ID
• Start and expiration times
• Acknowledgement state
• Linked Purchase Token presence
• Paused or canceled state context
• Test-purchase status
• Region
• Product ID
• Auto-renew status
• Prepaid plan
• Offer details
• Deferred item replacement
• Signup promotion

Failure of this optional request should not invalidate a successful order lookup.

Result presentation

Suggested sections:

1. Summary
2. Product and service period
3. Transaction identifiers
4. Payment and refund status
5. Current subscription status
6. Collapsible technical raw data

Suggested status colors:

• Green: valid and active or successfully processed
• Yellow: expired, canceled, pending or partially refunded
• Red: refunded, revoked or not found
• Blue: technical notice

Known Apple and Google status values should be translated into readable labels while also showing their original raw values.

Technical data and security

The original API responses could be available in a collapsed technical section after sensitive values have been removed or masked.

For Apple transactions, the technical section could state:

The transaction data came from an authenticated HTTPS response from the App Store Server API. The JWS payload was decoded for display.

It should not claim that full certificate-chain verification was performed unless this is actually implemented.

The feature should remain strictly read-only:

• No refunds
• No cancellations
• No subscription changes
• No purchase acknowledgement
• No entitlement changes
• No write-capable Store API endpoints.

[hyochan]

Shipped — order lookup is live in the dashboard now (#285). Thanks for the thorough write-up; the spec was detailed enough to implement almost as-is.

Where: project dashboard → Orders. Pick App Store or Google Play, paste the order ID, look it up.

What you get, in the sections you suggested: summary (product, type, state, environment, dates, price), transaction identifiers, payment & subscription status, and a collapsible raw payload. Status colors follow your green / yellow / red / blue convention, and the Google purchase token is masked by default with separate Show and Copy actions.

Both optional status fetches are implemented and, as you asked, a failure there never invalidates the order result — the reason is shown next to the order instead:

• Apple: getAllSubscriptionStatuses for auto-renewable orders
• Google: subscriptionsv2 for subscription line items

Credentials: it reuses what the project already has configured for verification, so there is usually nothing new to set up. Two caveats worth knowing:

• Apple lookups are production-only (order IDs do not exist in sandbox — you called this out), and because the lookup always verifies against production, the project also needs its App Apple ID filled in under Settings → iOS. It is optional for sandbox-only verification, so some projects will not have it yet.
• Google lookups need the Play service account to have View financial data in Play Console, otherwise the Play API rejects them.

Privacy: lookups are proxied live to the store APIs. Nothing is persisted — IAPKit keeps no record of searched order IDs or their results.

Docs: https://openiap.dev/docs/kit-backend#order-lookup

One note on Apple subscription status: when a customer holds several subscriptions, the status is matched to the looked-up order by its originalTransactionId rather than taking the first one in the response, so the panel cannot show an unrelated subscription. If you hit an order where the details look off, please report it — real-world order shapes are the part that benefits most from field reports.

[LukasB-DEV]

Thanks a lot. Can confirm that it works as expected