Hey Hari,
The idempotency_key works on all our API requests as documented here [1]. This won't solve what you're trying to build though because it has a completely different purpose. Idempotent requests allows you to safely retry requests without accidentally performing the same operation twice.
The use case is that you're trying to create a charge but lose your connection for example and never hear back from Stripe on that request. You don't know if it ended up being successful or not which is problematic and can lead to double charges. To avoid this, you'd use a unique key when making each request to our API. That way, you can retry a given request with the exact same key and parameters and ensure that you get the original response instead of creating a second charge for example. Those keys also expire after 24 hours.
Here, you want to ensure that if a customer already exists, for example with that email address or that specific card, you don't create a duplicate. This will require some custom development on your end as it's not something we support directly. For example, you'd have your own database that stores all your customers and you'd search whether a customer with that email address already exists before trying to create a new one.
Separately, if you want to detect when someone uses a card that was used before, you need to store another bit of information. When you collect the card details from your customer you get a token id back (tok_XXX). You can then use the Retrieve Token API [2] server-side and get a Token Object [3] back with the `fingerprint` property.
That property is a unique identifier for a given card number in your account. This means that if I sign up today with my card and then I come back tomorrow with the same card under a different email address you'd see the same exact fingerprint on both tokens or card objects [4]. The idea then would be to keep track of all the card fingerprints you see in your database to detect a returning customer. Whenever a customer adds a new card you'd first look if you've seen that card fingerprint before in your database and decide to create the customer or return an error based on this.
Cheers,
Remi