Our business is in the payment processing space and one of our core products is a Payment Gateway API. In terms of security we issue an API Key, Signature and RSA Encryption for sensitive information in the payload all over SSL. Customers are given an API key per E-Commerce website so we can route & tag their traffic accordingly before sending it to VISA/MasterCard.

That said, we are finding our larger clients to be an issue recently. VISA reached out to let us know that transactions are coming from other websites in a different industry and need to be routed to the correct account. Nothing illegal, just needs to be classified correctly. Long story short, we're finding that our larger clients are sometimes just using the same API Key for multiple websites that they own.

We can require clients to include javascript hosted by us on their checkout pages. I was trying to brainstorm if there is a way to have it "phone home" so we can validate the origin/domain and then return a token they have to include in their API requests to us. Would something like this work or is their a better way that I'm not thinking of?

  • How strong do you need the validation to be? Presumably the merchant can also put code in the checkout page, in which case it's impossible for you to prevent them spoofing validation if they try hard enough. You can make it a hassle, but the client doesn't know the difference between your code and the merchant's, and you couldn't trust it to tell the truth anyhow. Frankly, this sounds like legal/contractual problem: if your merchants aren't following the terms of the contract, talk to a lawyer first, not an engineer.
    – CBHacking
    Jun 17, 2023 at 4:24
  • I hear what your saying but the merchants aren't doing it maliciously. Unfortunately, they were at the mercy of lazy developers. Regardless if their at fault or not, we don't want Visa calling us questioning our platform. So if there was a way to help mitigate the problem via technology before it ever made it to Visa it would be preferred. I suppose it doesn't have to be fool-proof, it's more to catch a simple/lazy mistake
    – chris
    Jun 17, 2023 at 4:29

1 Answer 1


So, you can certainly put script on the checkout page that pings your own servers (from the shopper's browser) to say "Shopper X is about to authorize a transaction for Y at merchant Z" and then refuse to process any transactions that you get from a merchant back-end that don't come with such a message. For browsers, you can even use CORS and trust that the Origin header is accurate (though you'll need to know the domains used for checkout for each merchant... which is probably reasonable regardless) rather than passing the merchant identity (assuming multiple merchants never share one domain). Assuming you don't need to prevent abuse of your service, just laziness, this is a reasonably good way to go.

However, you can't prevent a merchant from spoofing this. Assuming they can host their own script on the same checkout page, they can block the outgoing message to you, and spoof it from one of their own hosts, complete with a spoofed Origin header. There's no way to tell, from the other end of a network connection, what kind of client generated a request; it's all just bits on a wire, and any app can generate them.

You'd need a client-specific secret that was tied to a specific shopper, and not visible to the merchant. This could be done with cookies, but only if the shopper had some kind of account with you so you could authenticate them, otherwise, you just added a tiny speedbump to the spoofing process, where the merchant pings your service pretending to be a shopper, probably when the shopper first adds an item to their cart, and gets a client secret that they later use for the validation request; without some way to authenticated that shopper, you wouldn't know the difference.

The other option, of course, is don't let the merchant control the checkout page. You can let them give you theming data and logos and such for it, much as other ecommerce checkout solutions have, but no scripts. It would have to be your own domain served from your own server and running only code that you have authorized to include.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .