If you enable neither Shipping nor Sales Tax/VAT for any products in your E-junkie Admin, then our cart will not ask for any buyer destination/location at all and will not trigger obtaining any address during Checkout. However, if you do enable VAT on E-junkie's end, then we will apply the correct VAT for the buyer's destination in the cart before the order goes to Checkout. If you also require collecting a physical address, you can enable Shipping to trigger that but leave all shipping-related rates/weights/costs at 0.00 to disable adding any actual Shipping fees to the order.



The case of a mismatch in destination country provided in our cart vs. during Checkout varies according to payment processor; see each case described here:

http://www.e-junkie.com/ej/faq.shipping-destination-mismatch.htm



I think I already answered your IPN concern via email earlier, but for the benefit of others reading along, I will paste my answer again here:



We already validate the IPNs we receive from PayPal before forwarding the order data to your integration URL, so there is no chance our system would transmit data to your URL without having received a valid IPN (or equivalent payment confirmation from non-PayPal processors), and of course your integration URL would never be exposed to the public. If you suspect someone could guess your integration-submission URL and try to spoof our transmissions, you could do some verification of your own to confirm any POSTs to your URL are actually coming from our server, perhaps use the MD5-hashed handshake method suggested on our Integration help page (see Additional Variables section):

http://www.e-junkie.com/ej/help.integration.htm

zvikicoRegarding VAT: I couldn't find the option to block it in my PayPal account. Can somebody point me in the right direction?

If there's a mismatch, I will not get an IPN and have to process it manually? Is there a way to send the IPN later? (my system is automated, so I have no way of entering payments manually)

BTW, from my experience, PayPal IPNs are sometimes fail to verify on legitimate transactions. What happens in such cases?

Regarding the verification: How can I confirm the IPNs are coming from your server?

The MD5 handshake is constant as long as I don't change my username/password. This means that if somebody sniffed an IPN from your server to mine, he can easily spoof a message. Having a handshake which is an MD5 of other, not constant properties, public and obscure, (e.g. my password and the payer email) will greatly improve the security in this case.

Hm, you raise some interesting points there, ones which Development would be in a better position to consider and address, so I'll assign this to our Lead Developer's attention. I do like the idea in theory of having a "disposable single-use" MD5 handshake derived from one secret component (e.g. your password) and one dynamic component transmitted with the order data (e.g. buyer's email, or transaction ID, etc.)