Best practices for your online payments integration

Follow these best practices to ensure your standard integration for online payments is secure, performant, and compliant.

Requirements

Before you begin, take into account the following requirements, limitations, and preparations.

Keep your integration up-to-date

Staying up-to-date on the latest version of Drop-in is crucial for new features, security updates, and compliance.

Handle web framework re-renders

Modern frameworks can re-render UI components, which can cause unexpected behavior in the checkout. To prevent this, initialize AdyenCheckout and mount your instance of Drop-in only once, when you are ready to display the payment methods.

Some web frameworks might require some extra attention when using specific approaches.

• React.StrictMode: This leads to re-renders and re-executions of effects and callbacks. Ensure that AdyenCheckout and Drop-in are not initialized multiple times.
• Custom hooks: You can encapsulate the initialization of AdyenCheckout in a custom hook. If you do, ensure your hook returns the instance of the Drop-in that you mount in your UI. And most importantly, make sure that the mounting is executed only once, in the React component that consumes that hook.

For example, when using a custom hook in React, ensure the component is not mounted multiple times on re-renders.

Manage Server-Side Rendering (SSR)

Drop-in depends on browser APIs like window and document. If you use SSR, make sure the code that creates an AdyenCheckout instance and mounts Drop-in is executed on the client side.

Securely implement a custom pay button

If you use a custom pay button in your integration, you need to take a few things into account.

Prevent multiple submissions

A shopper can trigger a payment in multiple ways, for example by selecting the Pay button, or by pressing the Enter key on their keyboard. To prevent multiple payments for the same order, you must disable your pay button as soon as a payment attempt has been made.

You can detect when the payment flow is triggered by using beforeSubmit in your AdyenCheckout configuration.

The beforeSubmit event is triggered when the shopper selects the pay button.

Unsupported payment methods

The custom pay button is not supported for:

• PayPal
• Klarna
• Click to Pay

For these payment methods, you must use the button provided by Drop-in.

Use HTTPS for your checkout

To protect sensitive payment data, host your Adyen checkout on a page that uses HTTPS.

In your live environment, you need to use HTTPS. It encrypts the connection between the shopper browser and your server, which prevents data interception and tampering. If you do not use HTTPS in production, it leads to security warnings and can cause payments to fail.

For local development and testing, you can use HTTP. However, make sure you switch to HTTPS before you go live. Read about end-to-end online payments testing for more information.

Avoid <iframe> elements

We do not recommend integrating your checkout in an <iframe> due to potential complexities. When an <iframe> is hosted on a different domain than its parent, redirect payment flows do not work. This is because the <iframe> cannot redirect when the parent is a different domain. This restriction leads to failed transactions and a poor user experience. Some payment methods may also behave differently or require a specific configuration when used in an <iframe>.

If you must use an <iframe>, host it on the same domain as the parent page.

Avoid WebViews

For native mobile apps, we recommend that you do not use WebViews to display the checkout.

WebViews are less secure and functional than native components and can cause performance issues, especially with payment methods that require redirects.

Instead, you should implement native components, for example:

• Custom Tabs for Android
• SFSafariViewController for iOS.

Ensure browser compatibility

We designed Drop-in to work seamlessly with recent versions of all major browsers. To ensure the highest security standards and optimal performance, we focus on modern browsers that receive regular security updates.

Supported desktop browsers

Supported mobile browsers

Understand cookie usage

Drop-in may set one cookie, _RP_UID, which is generated by our internal risk management module. This module is enabled by default and helps identify suspicious browsing or purchasing patterns. We do not recommend disabling it.
Other cookies, from adyen.com, may be present if you previously visited our websites and accepted cookies. To see only the cookies used by your integration, clear your browser data or use an incognito window for testing.

Manage possible interactions with browser extensions

We do not take responsibility for how Drop-in interacts with browser extensions like ad blockers, cookie managers, or password managers. An improperly configured extension can block an <iframe> or other elements required for payment methods to function correctly.

Enhance your integration with Adyen Uplift

We recommend that you use features of Adyen Uplift in your integration to increase payment conversion, simplify fraud management, and reduce the cost of payments.

Adyen Uplift looks at your company's data, how your account is set up, which features and products you use, and which optimizations could make it even better. For a standard integration, you can keep the default Adyen Uplift settings. Periodically check the recommendations to find out if there are any potential opportunities to improve, such as adding a payment method.

Manage client-side resources

There are two ways to load the client-side resources for Web Drop-in:

• Recommended
  Load through the Adyen Web npm package.
• Embed the Adyen Web script and stylesheet into your HTML file.

Embed the Adyen Web script and stylesheet into your HTML file

When embedding the script and stylesheet, make sure that the URL region matches with the region of your live endpoints and the environment you configured for Drop-in in your integration.

We also recommend to use Subresource Integrity hashes to ensure security.

Implement Subresource Integrity hashes

We recommend that you implement Subresource Integrity (SRI) to ensure that the files you are loading from Adyen have not been manipulated or tampered with by malicious actors.

To use the SRI hash, you need to add an integrity attribute when specifying <script> or <link> elements. Browsers will also check for the crossorigin attribute to ensure that the origin allows Cross-Origin Resource Sharing (CORS). If a browser detects that the file's hash does not match the specified hash, the browser will not load the resource. To know which browsers support SRI, refer to this browser compatibility list.

Adyen provides the SRI hash that you include as the integrity attribute. You can find the SRI hashes for all versions of our JavaScript and CSS files in our release notes, under Updating to this version.

Test your integration

When you have a working online payments integration, test:

• In a secure context
• On real mobile devices

For more information, read:

• End-to-end testing documentation, providing more general testing advice.
• Testing payments and modifications documentation, listing scenarios you can test your integration on.

See also