支付成功确认后，需校验IPN POST请求中的哪些变量？

1. Is payment_status == "Completed" the only indicator of a successful transaction? #

Short answer: Yes, but only for finalized successful payments—context matters though. For subscriptions, you’ll need to pair this status with the right txn_type (like subscr_payment for recurring subscription charges) to make sure you’re processing the correct event.

That said, Completed is the only status that guarantees funds have been successfully deposited into your account. Statuses like Pending (e.g., an eCheck waiting to clear) or Failed are not final, so you should never treat those as successful transactions.

2. Critical IPN Variables You Must Check (Beyond payment_status) #

These checks prevent fraud, duplicate processing, and edge cases that could break your subscription records:

A. First: Verify IPN Message Authenticity #

Before checking any variables, send the entire IPN payload back to PayPal’s verification endpoint and only proceed if you get a VERIFIED response. This is non-negotiable—skip this step, and you’re wide open to fake IPN attacks.

B. Transaction & Account Validation #

• receiver_id (preferred over receiver_email): This is your PayPal account’s unique, unchangeable ID. Confirm it matches your account’s ID to ensure the payment is being sent to your business, not a malicious actor’s.
• receiver_email: If you use this, double-check it’s exactly your registered PayPal business email (note: emails can be changed, so receiver_id is more reliable long-term).
• txn_type: For subscriptions, validate this matches the event you expect—e.g., subscr_payment for a successful recurring charge, subscr_signup when a user first subscribes, or subscr_cancel if a subscription is ended. This prevents processing irrelevant IPNs (like refunds or disputes) as successful payments.

C. Amount & Currency Checks #

• mc_gross: Compare this to the exact amount you expected for the subscription plan. Fraudsters might tamper with IPN data to make a $1 payment look like a $100 subscription—this check stops that dead in its tracks.
• mc_currency: Ensure it matches the currency you use for your subscriptions (e.g., USD, EUR). This avoids mismatched currency transactions that could cause accounting headaches.

D. Prevent Duplicate Processing #

• txn_id: Every PayPal transaction has a unique txn_id. Before processing an IPN, check your database to see if this ID has already been handled. If it has, skip processing—this stops duplicate IPN messages (PayPal sometimes retries IPNs) or replay attacks.

E. Subscription-Specific Checks #

• subscr_id: This is the unique ID for the user’s subscription. Store this with your user’s record to link future recurring payments, cancellations, or plan changes to the correct subscription.
• custom: If you passed a custom value (like your system’s user ID) when the user initiated the subscription, this variable will be returned exactly. Use it to map the IPN to the correct user in your database (never trust payer_email for this, as it can be forged).
• item_name/item_number: If you offer multiple subscription tiers, confirm these match the plan the user signed up for. This ensures you’re recording the correct subscription type for the user.

Final Tips #

• Log everything: Save full IPN payloads, verification results, and processing outcomes. This is a lifesaver for debugging issues with PayPal support or user disputes.
• Handle non-Completed statuses: For Pending payments, set up retry logic to check back later if the status updates to Completed. For Refunded or Dispute statuses, update your subscription records accordingly (e.g., pause access if a dispute is filed).

内容的提问来源于stack exchange，提问作者Acsor