> True, you'd want your customers to already be expecting an > email from you with the link at that time of the subscription > period.
If it is fundamentally insecure and risky why try and modify the implimentation to make it secure? The whole idea of this topic is that the secure account functionality be extended to invoicing as well as payer initiated payments. Incoming payment control functionality would also help merchants to prevent incoming payments they cannot easily link with a customer identity and/or order number. > Sounds interesting. The only potential problem I can foresee > would be aiding the creation of a horrible new form of spam > that's internal to the payment system to go along with all the > external spam we see via email (but maybe if it cost a bit to > submit the invoice, payable to the proposed payee??). > JMR Account holders should have incoming invoice control functionality to regulate and authenticate invoices. The simplest way to do this would be to allow receipt of invoices only from an approved billers list, established by the account holder. Essential information for a valid invoice would be: (approved) Payee, Amount, Invoice Number, and Due Date. Optional information would include order number and a description or purpose. Ideally, the biller should be able to send full invoice details in the form of a pdf file, for the account holder to view, download, save and print as desired. Invoicing functionality does introduce some possible complexity, but I think that it would be worthwhile considering the following invoice related functionality: 1. Recall or Cancel incorrect invoices and replacement with a corrected invoice if required. This process must be controlled by the invoicer -- the payee can contact the payer if he finds a problem/has a problem, and this rule would prevent the payment system being a forum for dispute. Note that recalled or cancelled invoices must be incapable of being read and/or paid respectively. 2. Future dated payments, so that payers can pay invoices on their due date. For guaranteed payment processing account funds could be allocated against such invoices and unavailable for other payments, or payments would be contingent on available funds. 3. Activity notification, e.g. generate email/SMS notification on invoice arrival, invoice due in x days etc. (to be controlled by payee). 4. Invoice tracking. Invoices lifecycle could be tracked as follows, with Condition= (Unpaid, Paid) and Status= (Recalled, Unread, Unapproved, Approved Unfunded, Approved Funded, Overdue, Rejected, Cancelled). (To qualify as approved, a payment must be booked for payment on or before the due date.) 5. Receipts and Notifications. The payer should be able to have the option of sending a 'Read' receipt, a 'Rejection Notice', 'Approved Unfunded Notice' and/or 'Approved Funded Notice.' 6. Conditional pre-approval. Payees could set up billers that they would pay invoices from automatically, subject to available funds, and other conditions (e.g. not to exceed x, order number = 123, due date =y etc.) I suggest that invoices be charged a fixed fee for each time the invoice is sent, e.g. 0.1g, charged at the time that the invoice is sent. This fee would be charged again for a cancel-reinvoice, and should not be refunded for recalls of cancellations. David Hillary --- You are currently subscribed to e-gold-list as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Use e-gold's Secure Randomized Keyboard (SRK) when accessing your e-gold account(s) via the web and shopping cart interfaces to help thwart keystroke loggers and common viruses.
