Handle payment notification requests from PayPal for existing donation
POST request (must be validated, HTTP 406 error if other method was used)
Request model parameters:
- payment_status, see https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNandPDTVariables/#id091EB04C0HS Only some are handled (see below)
- txn_type: Transaction type, see https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNandPDTVariables/#id08CTB0S055Z Of the txn_type beginning with subscr_, only subscr_payment is handled, the others are silently dropped.
- item_number, spenden_id, sid. Donation ID (from GET/POST params), pick first non-null value from this list
- custom: JSON-encoded custom data:
- sid, id. Donation ID. Pick first non-null value from this list if donation id was not in in GET/POST from previous data
Values that are being stored for documentation purpose only:
- paypal_payer_id => payer_id
- paypal_subscr_id => subscr_id
- paypal_payer_status => payer_status
- paypal_address_status => address_status
- paypal_mc_gross => mc_gross
- paypal_mc_currency => mc_currency
- paypal_mc_fee => mc_fee
- paypal_settle_amount => settle_amount
Values that are being stored for later export:
- txn_id => ext_payment_id
- payment_type => ext_payment_type
- payment_status => ext_payment_status
- payer_id => ext_payment_account
- ext_payment_timestamp (generated at runtime)
- subscr_id => ext_subscr_id
As the first step, the handler must post back the raw POST data (with the additional field cmd=_notify-validate) to the PayPal URL to signal that the request was received (See https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNImplementation/#specs). If posting back was not successful (got no 200 OK back or response content is not VERIFIED), the script has to quit.
Now the script does different things, depending on payment_status (see below).
If we're using the PayPal sandbox, set to Processed, otherwise ignore. Check if the sandbox still does not send Processed, otherwise just ignore.
Completed and Processed
Handle according to donation status. Do nothing except logging for states that don't make sense. Create a new donation record (with data from the old record) when status is "B" (bezahlt) and txn_type is subscr_payment. Process (new) donation.
Handle the status changes outlined in T130190.
The payment processor does not check the utoken, only the token, because payments can come in up to 5 days after creating the donation.
Other status strings
Log and do nothing. In the future we should check with the fundraising team, which states make sense in our context and which are already handled by defaults and Backend Application actions.