according address appreciate business buyers cart clients common cost customers development effective ejunkie existing feature features frankly general issue merchant merchants number numbers option overall paid particular parts paypal personal problem problems programming refund regarding regular reply require service solution stability support system tyson written

We like ejunkie but now have a problem with VAT reconciliation.

We need to be able to identify EU customers that are VAT registered. There is no option to ask customers to tick a box or to enter a number. We need something to be able to identify them for our VAT returns.

We can't just assume as we have a mix of business and personal customers.

Ejunkie: Any plans to address this issue for your EU clients?

Anyone else: Have you found a workaround or a cart as cost effective and simple as ejunlie that manages this? We're using PayPal.

We have no means to support validation of VAT numbers. We can only calculate VAT by treating all buyers as regular end-consumers. You can ask affected commercial buyers to provide their VAT numbers privately, so you could validate that on your own and refund any VAT paid.

That's not a feasible, cost effective solution I'm afraid.

Given this is possible what's the underlying barrier to implementing this? Cost, lack of interest in the EU market, other development priorities?

Frankly, it's more a lack of interest ~from~ merchants in the EU in general, and regarding a live VAT number validation feature in particular.

Development prioritizes new feature requests according to broadest potential benefit and the simplicity of programming them into our existing codebase and algorithms. Because ours is a centrally-managed service that is shared in common among thousands of merchant subscribers, it's impossible for us to make a modification for one merchant that does not also affect all other merchants, so we place the utmost importance on maintaining bug-free stability for all merchants using our system.

Greater priority is given to popularly-requested features which many or most merchants could benefit from, and which can be written into our existing system fairly straightforwardly with minimal risk, whilst lower priority is given to features rarely requested and of benefit to fewer merchants, or which require substantial reprogramming or complexity that may introduce new bugs or instability problems in well-polished and stable parts of our existing system.

Thanks Tyson,

That's a surprise (the low interest from EU merchants). The overall devt strategy makes perfect sense. I appreciate the reply.

Thanks.