In today’s iteration, we have replaced the balance history page with a Payments history page that makes more visual sense than the old one.
In all honesty, when we launched the new payment model, our focus of attention was on invoices and invoice payments. However, we soon found out that most of our customers’ required proof of payment – even if payment was made to the escrow account (not to an invoice).
And so, in addition to the Payments history page, payments made from external funds (i.e. cash deposit, wire transfer, Moneybookers and credit card) now have a clickable link that opens up a Proof of Payment that can be printed for accounting records. That document also explains what actions took place on receipt of the payment (e.g. payment towards invoice, payment to escrow account etc.)
We will eventually seek to upgrade the payments page to integrate invoices, thereby providing you with a “Statement of Account”. But that won’t be taking place until 2012.
In today’s iteration, we’ve added support for credit and debit cards issued by Visa and MasterCard.
As per their rules & regulations, we can only accept card payments on a post-paid basis (i.e. to settle invoices) and not for escrow deposits.
You will notice that we have labelled the card payment option with *beta*. This means that we have tested card payment integration to a level of satisfaction we believe is ready for public consumption. However, we would not be surprised if an issue (or two) arose which we failed to account for.
So, although we will closely monitor card payments, we encourage you to get in touch if you feel that something is amiss.
In today’s iteration, we have updated the way in which we notify you of failed HTTP requests issues by the SMS API.
Previously, your technical contact would be notified every time a HTTP request fails to be delivered after our retry schedule has attempted several times. Although it took us a long time to realise this (no-one raised it with us), this set-up inevitably meant that, when an application was broken, the mailbox of your technical contact would be flooded by our notifications.
With today’s update, we (internally) label your application as broken the first time a HTTP request fails to be delivered despite many attempts. We then remove that label once another HTTP request succeeds. We send your technical contact *1* failure notification when the application breaks and don’t send any more until it has been fixed (and then breaks again).
This fix, therefore, protects the mailbox of your technical contact from being flooded by failure notifications when just the one will do.