paypal ipn vs webhook event mismatch on chargeback
Reconciles PayPal IPN and webhook chargeback events that disagree: declaring webhooks the system of record, mapping IPN statuses to webhook types, and correlating by transaction id. Use when both feeds are active and the ledger shows conflicting states. Not for single-feed delivery failures.
TL;DR
PayPal IPN and webhooks describe the same chargeback with different field names and different timing. Pick webhooks as the system of record, map IPN payment statuses to webhook event types, correlate both feeds by transaction id, and retire IPN once the two agree.
paypal ipn vs webhook event mismatch on chargebackUse this when
- IPN and webhooks disagree about a chargeback's state.
- Your ledger shows conflicting states for one transaction.
- You run both feeds and want to consolidate.
Not for this skill when
- Only one feed is active and events are missing. That is a delivery issue.
- The mismatch is between PayPal and your processor of record.
Steps
- Declare webhooks the system of record and stop writing ledger state from IPN. Verify: new IPN messages are logged but do not change state.
- Build a mapping table from IPN payment_status values to webhook event types for chargebacks. Verify: every IPN status you have ever seen maps to something.
- Correlate both feeds by the PayPal transaction id and list the disagreements. Verify: each disagreement names the transaction and both claimed states.
- Resolve each disagreement in favor of the webhook state and record the correction. Verify: the ledger matches the webhook feed end to end.
- Once the feeds agree for a full chargeback cycle, disable the IPN listener. Verify: no code path still writes from IPN.
Variant phrasings
paypal ipn webhook chargeback conflict
Conflict-wording search.
paypal webhook vs ipn different status
State-wording search.
migrate paypal ipn to webhooks chargebacks
Migration-wording search.
Compatibility: PayPal IPN (legacy) and PayPal webhooks. Both remain available, but webhooks carry the richer event model PayPal now develops against.
Why it happens
IPN is the older system with coarser statuses; webhooks came later with finer-grained events. The two were built years apart, so the same underlying chargeback surfaces under different names at different moments. Running both without a declared winner guarantees conflicting state.
Edge cases / pitfalls
- IPN can arrive before the matching webhook. Do not treat early IPN as a conflict.
- Some IPN statuses have no webhook equivalent. Your mapping table needs an explicit unknown bucket.
- Keep the IPN log for a while after cutover. Auditors like the second witness.
- If a third-party plugin writes from IPN, find it. Silent writers undo the migration.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_vVAcLlp8XazXvxxuyN50SQ