At Elements we understand that card tokenization is on the critical path of your business. Therefore, we have designed our systems with transparency and reliability as top priority. Through this design, Elements guarantees all systems have a definitionally higher uptime than your default payment service provider.

To achieve this, we have implemented a client-side failover strategy in our SDKs and libraries. When you experience issues talking to Elements server (e.g. 500 and 403 errors), our SDKs and libraries automatically recover and talk to your specified PSPs directly. In this worst-case scenario, your application falls back to your current (i.e. pre-Elements) experience.

The SDKs and libraries are hosted directly in your app and we are happy to provide source code for both transparency and ease of debugging.


When used properly, Elements.js is loaded directly from our CDN (Amazon CloudFront) which has the typical benefits of both low-latency and very high uptime.

In order to limit your website's PCI scope, Elements.js loads a static HTML into an iframe. This HTML page is similarly served directly from our CDN.

As a result only bugs in this software itself would be the source of errors:

With our enterprise customers, we share readable source client-side code to engender your confidence.
We have strict versioning and share anytime we have a planned update. You can always peg to a specific JS version (which in turns pegs to the iFrames HTML).

Client-side Fault Tolerance

Each of our client libraries (web, iOS, Android) gracefully handles the rare intermittent failures of our backend servers.

If the request to our service returns an non-deterministic response, we then fallback on the client-side to the configured default tokenization service (e.g. Stripe).

We additionally adopt a strategy of "fail-fast" in order to minimize end-to-end latency in the case of a failure.

By the nature of this design, it is possible that you do not have all the tokens for all the PSPs that you desire in spite of our best effort attempts. If this is the case, for a particular user you must use one of the processors of whose you have a token.


Stripe's one-time token vs source token

By the nature of Stripe's system, in the failure scenario where the Elements backend fails to respond with deterministic response, we are only able to return an ephemeral Stripe token (vs the typical persistent tokens we otherwise would return).
Please continue to use your previous code paths in this edge case.

Incomplete PSP Tokens

In the worst case, you may only have some of the tokens for a given card and be forced into a degraded state.

If you aren't using our charge service, your backend can call the appropriate PSP charge api based on the subset of tokens that you do have.



We can use a nightly reconciliation to repair customer information for a subclass of transient errors.

Auto Fallback Against Server Errors

Our SDK will automatically failover to Stripe native tokenization flow when a 500 server error is experienced if a stripe publishable is provided during SDK initialization. This guarantees that your business and customer experiences wouldn't be interrupted even if there is a server issue on our side.
For example, you can use card 6555 5555 5555 5555 with CVV 500 in sandbox environment to trigger a 500 error on our server.