Using PayPal subscription IPN fields to manage user accounts -

i'm using paypal take subscription payments access website service.

i'm using paypal's ipn manage payments , user accounts.

i'm sending custom random key paypal, unique each user, when subscription first instantiated same key sent every ipn. means can bind users table paypal notifications positively.

accordingly can generate database list of user_ids , notification details.

so need figure out best logic use calculate each users current payment status and, consequence, account - whether continue allowing access, suspend or delete user account. decision come down whether payments still coming through or not.

a bunch of interesting varied data comes through on paypal's ipn - looks irrelevant in terms of user account management couple of columns quite useful. specifically...

1. field outstanding_balance appears contain - value 2dp of money still owing. far during testing figure has ever been 0.00

2. field txn_type shows me selection of different codes: subscr_signup (when user sets subscription), subscr_payment (when payment appears successful), subscr_cancel (this seems appear whether customer or vendor cancels subscription), , subscr_eot (end of term - 1 crops shortly after subscription cancelled).

my impulse search table recent txn_type="subscr_payment" entry each user account, , check date last notification arrived. if date stamped over, say, 28 days ago account can suspended... if it's on 56 days account can deleted.

is idea? or there better logic can employ?

i've done this. quite simple:

1. don't grant access until receive first payment. can intial signup , payment in either order.
2. paypal notify if cancel subscription or expires. when either of those, deny access effective date.
3. if recent payment status on account 'reverse', suspend access until either 'cancel reverse' or situation sorted out in other way.
4. don't count days. paypal counts days. can repeating disagreement, , guess who's right? paypal. , guess isn't wrong? customer. don't want penalise customer because paypal got behind or had different idea of 28 days yours. you've handed responsibility collections , renewals paypal: let them it.

5. beware of building policy this. should mechanism, , should manually overridable. example, actual evaluation of whether user has access product mustn't computation on payment history. simple lookup of table, ipn code can modify, can humans. example: there dispute. lost. might matter of business want keep customer alive grace period anyway. alternatively might in extremis want fire customer immediately, e.g. usage violations.

6. you can ignore balance field. important thing txn_type.