Handle pending transactions on app startup different validation?

[iim-norse]

what a different here: https://hyochan.github.io/expo-iap/guides/purchases#pending-and-unfinished-purchases

isValid = await validatePurchaseOnServer...

and
isAlreadyProcessed

useEffect(() => {
  initConnection().then(async () => {
    const purchases = await getAvailablePurchases();
    for (const purchase of purchases) {
      if (await isAlreadyProcessed(purchase)) {
        await finishTransaction({purchase});
      }
    }
  });
}, []);

this is different calls to backend ?

[gitdogdev[bot]]

Key Difference:

Both approaches call your backend, but they serve different purposes and are used at different times:

1. validatePurchaseOnServer() (in onPurchaseSuccess)

• Called immediately after a fresh purchase is made
• Validates the receipt/token with Apple/Google to ensure it's legitimate
• Security-critical: prevents fraud by verifying the purchase is real
• Must complete before you grant access to the user
• Example: User taps "Buy" → purchase completes → validate on server → grant access → call finishTransaction

2. isAlreadyProcessed() (on app startup)

• Called when checking pending/unfinished transactions at app launch
• Checks if your backend already processed this purchase (e.g., user bought it, you granted access, but transaction wasn't finished)
• Not validating with Apple/Google again—just checking your own database
• If already processed: just finish the transaction. If not: process it first, then finish.

Why the difference?

• Fresh purchases: Need Apple/Google validation to ensure authenticity
• Pending purchases: You already validated them before. Now you just need to check if your backend recorded it, then clean up the transaction

From the docs:

From the docs:

"Always finish a transaction, even if you couldn't validate it. This prevents the transaction queue from growing indefinitely." — Apple StoreKit docs

However, you should validate before granting access, not before finishing.

---

Practical Flow:

APP LAUNCH
├─ Check for pending transactions
├─ For each pending transaction:
│  ├─ Call isAlreadyProcessed(productId, receipt)
│  ├─ If true: Just call finishTransaction() (already gave access)
│  └─ If false: Call validatePurchaseOnServer(), then finishTransaction()
│
FRESH PURCHASE (user taps "Buy")
├─ SKPaymentQueue calls paymentQueue(_:updatedTransactions:)
├─ Transaction state = .purchased
├─ Call validatePurchaseOnServer() immediately
├─ If valid: Grant access + update UI
├─ Call finishTransaction()
└─ If invalid: Call finishTransaction() anyway (don't grant access)

---

Summary Table:

Scenario	Function	Validates with Apple/Google?	Checks Your DB?
Fresh purchase	validatePurchaseOnServer()	✅ Yes	✅ Yes (marks as processed)
Pending transaction at startup	isAlreadyProcessed()	❌ No	✅ Yes (checks if already marked)

---

Bottom line: They're complementary, not redundant. One validates authenticity, the other prevents duplicate processing. Use both.

---

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!

[hyochan]

@GitDog Good explanation! One small addition for the isAlreadyProcessed case:

if (await isAlreadyProcessed(purchase)) {
  await finishTransaction({purchase});
} else {
  // Don't forget this case!
  const isValid = await validatePurchaseOnServer(purchase);
  if (isValid) await processPurchase(purchase);
  await finishTransaction({purchase});
}

The docs example only shows the true case - make sure to handle unprocessed pending purchases too.

[gitdogdev[bot]]

@hyochan Absolutely right! Thanks for the clarification. The critical point I should have emphasized:

The else case is mandatory — when isAlreadyProcessed() returns false, you must:

1. Call validatePurchaseOnServer() to validate the receipt with Apple/Google
2. Only grant access if validation succeeds
3. Always call finishTransaction() regardless

The docs example only shows the true case, which can be misleading. Your code snippet shows the complete pattern:

if isAlreadyProcessed(transaction) {
    // Already validated and granted
    await transaction.finish()
} else {
    // NEW purchase - must validate
    if await validatePurchaseOnServer(transaction) {
        // Grant access
        await grantAccess()
    }
    // Always finish, whether validation succeeded or failed
    await transaction.finish()
}

This is the correct and complete pattern. The key insights:

1. Server validation is non-negotiable for security. Never trust the client alone.
2. finishTransaction() must always be called — it tells StoreKit the transaction is handled, preventing re-delivery.
3. The docs example is incomplete — it shows happy path only, which leads developers to miss the else branch.

Common mistakes to avoid:

• ❌ Calling finish() inside validatePurchaseOnServer() — you lose the transaction if validation fails
• ❌ Only calling finish() on success — unfinished transactions re-deliver endlessly
• ❌ Skipping server validation — vulnerable to receipt spoofing
• ❌ Granting access before server validation completes — user gets free access if validation fails

Best practice structure:

for await result in Transaction.updates {
    let transaction = try checkVerified(result)
    
    if isAlreadyProcessed(transaction) {
        await transaction.finish()
        continue
    }
    
    let isValid = await validatePurchaseOnServer(transaction)
    if isValid {
        await grantAccess(for: transaction.productID)
        await markAsProcessed(transaction)
    }
    // Always finish
    await transaction.finish()
}

The server validation step is where you check the JWS token against Apple's or Google's servers — it's the firewall that prevents fraud.

---

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!