Identified Payments and Renewals

Publishers can now build pages to accept Renewals or Payments from subscribers following a Dynamic Account Lookup. These transactions are referred to as "Unsolicited Identified Payments" (UIP) or "Unsolicited Identified Renewals" (UIR). "Unsolicited" refers to the fact that the payments or renewals are not the result of a selected promotion, but are more or less ad hoc transactions. The implication of this is that since they were not selected out of an update via a renewal or payment macro, they will not have information such as effort, package, bill key or renewal skey associated with them. This requires the publisher to determine the information they want to associate with the transactions and hard code it into the transaction. You may be able to discern appropriate settings based on information returned from the lookup, such as prior source or prior sourcekey and dynamically generate the settings. This will require more sophisticated page development and testing. The transactions will show up in standard reports, but not necessarily under the skey you might expect. For instance, say you decided to assign all UIR's keycode "0", and sourcecode "WEB". You may have selected a subscriber for a third effort renewal, but they renewed following an account lookup. They will report under the skey you assigned on the renewal page (0 and WEB) rather than the skey they were selected and promoted under. This will reduce the returns and renewal percentage of the third effort renewal, but not the total number of renewals received. "Identified" refers to the fact that the lookup will provide the matchcode of the subscriber. Transactions with matchcode are considered "identified" within the Kable (NPS) system. For payments, the ordernumber is also returned if the subscriber has an open credit order on file. The ordernumber and matchcode are required to process a payment.

Checklist