Hi
I’m currently looking at FreeAgent as a replacement for my business’
current Freshbooks account of several years, for various reasons, including
the bank feed, attached PDF and RESTful API features.
However, our biggest issue is integrating FreeAgent with our payment
gateway. Ideally, I’d like to send a “secure” (not very easily guessed)
link to a payment form, within each invoice notification email.
We could possibly use the email template variable [reference] as a resource
within our secure link, like so:
https://secure.site/pay/[reference]
Then when the customer clicks on the link, our application listening at the
above URL initiates a call to our account at FreeAgent via the API for the
invoice with that reference.
We’d like to show the customer the details of their invoice again, before
they continue to be redirected to our payment gateway’s PCI compliant
payment page. This is where the issue of (reasonably) secure payment links
comes in. As anyone who’s built applications for the web knows, you can’t
expose potentially sensitive information via easily guessed URLs. In the
above case, the reference generated by FreeAgent is a sequential integer.
We’d of course implement blocking/throttling of clients who request too
many invalid, or already paid for links, but we’d like to have more secure
links from the outset, so that we don’t have to prompt our customers for a
login in order to be more justifiably paranoid. Once paid, then that secure
URL is disabled (marked as used) as an added precaution.
I’d like to suggest possibly adding a field to created invoices, which
stores a long enough (but not too long to be impractical) random looking,
unique string (unique to the specific FreeAgent account, of course), as a
more secure key into each invoice. This would enable the above reasonably
obfuscated method of integration with external payment gateways.
So, instead of https://secure.site/pay/2345
A less guessable URL of https://secure.site/pay/geytgmrugu3demjrgi3domjs
It needn’t be something added to the data structure necessarily - it could
possibly be implemented at run-time by encrypting the invoice number using
the API key as passphrase with a known algorithm. Then when clicked on by
the customer, our application listening at the secure link decrypts the
“pay token” from which it extracts the applicable invoice number.
Whichever method used to generate a “pay token” linked to a particular
invoice, it could be exposed via both an email template variable (say
[pay_token]) and an API invoice field pay_token.
Hopefully the above explanation is clear and motivates for this feature.
Would anyone else here find it useful? Alternatively, if I’ve missed a
better way of integrating with our payment gateway, please point me in the
right direction. Thanks.
Regards
Dale
