# Payment element FAQ

The payment element is a secure, embeddable UI component that allows you to accept local payment methods from around the globe.
To help users of both one-time and recurring payments accept multiple different payment methods, the payment element supports 3 main integration paths. See our integrations guides for each path:
* [One-time payments via PaymentIntents](https://stripe.com/docs/stripe-js/payment-element/accept-a-payment)
* [Subscription payments via PaymentIntents](https://stripe.com/docs/billing/subscriptions/elements#collect-payment)
* [Subscription payments via SetupIntents](https://stripe.com/docs/stripe-js/payment-element/set-up-payment)
## FAQ
### What are the core features of the payment element?
- Support for multiple payment methods via a single elements integration
- It surfaces relevant payment options to each buyer through sorting logic based on customer country location (derived from IP address) and preferred language (derived from browser locale)
- It's [localized for 42 locales](https://stripe.com/docs/js/appendix/supported_locales)
- It can be styled to merchant brand (font, colors, spacing, etc.)
- It is mobile responsive
- It has in-built input validations
- It is PCI-DSS Compliant
- It works with PaymentIntents/SetupIntents
### How does the payment element relate to Stripe Checkout?
You can create a Stripe Checkout flow with elements, a set of prebuilt UI components, like inputs and buttons. For each payment method (credit cards, debit cards, etc.), there’s an associated element. The payment element is a  component that combines individual payment methods into a single element.
If not using the payment element, a merchant would need to build and maintain a currency/country/payment method mapping and associated logic for when to call Stripe APIs on the backend and to show/hide the elements on the user interface (UI). This would require integrating each element one by one.
With the payment element, it is possible to remove the need for a merchant to build and maintain these aspects. The integration experience starts to look like a single element integration, the mappings, logic, presentation, and behavior are pre-built by Stripe. The trade off is slightly less customization within the UI layer, but more control than what the full page Checkout offers.
How does the payment element differ from other elements?
- The payment element requires nearly the same amount of effort to integrate as another element (for ex., the Card Element), but requires far less effort to maintain, since payment methods can be added without needing to integrate with another element for each one.
- The ability to customize styling is more limited compared to elements today, with only our JavaScript styling API supported (not CSS). However, the majority of styling capabilities are still supported.
- Because server-side confirmation isn't supported, credit cards will need to use webhooks (not the case with Elements today). However we are going to support a bypass for this on Cards.
- A redirect to an order confirmation page is required for most payment methods accepted via the payment element, so single page web-apps will need to add a separate page for order confirmation. However, the checkout experience is still fully embedded within the merchant's site (unlike Stripe Checkout).
### How does the payment element relate to other Stripe Checkout UI options?
The payment element is a  **UI component that can be placed within a merchant website**, styled and branded to the merchant experience. It allows you to offer multiple payment methods (18+ and growing) with drastically less effort automatically collecting the necessary information from consumers (except shipping address). The payment element uses Stripe’s payment APIs (PaymentIntents/SetupIntents/CheckoutSessions) to function and is built on top of our SDK, Stripe.js. This product is designed for merchants who want control over the payment experience offered. More specifically, if you’re looking to fully integrate payments within your web application (i.e. multi-step flows, brand conscious, high need for control, present special terms at checkout), then payment element is the product for you. Payment element allows you to collect any information you need during checkout and design the experience you want.
On the other hand, the full page Stripe Checkout UI is **our fully optimized payment page** that also makes it easy to offer LPMs (75+) which your site would redirect to, but comes with limited styling options (color/logo). Stripe Checkout full page and embedded form only uses CheckoutSessions to operate and does not use Payment Intent/Setup Intent. The full page and embedded form offers and collects more info, including shipping address collection and shows a product list / order total and submit button, which the payment element does not.
### How much effort is it to implement the payment element?
The payment element requires nearly the same amount of effort to integrate as a single element (for ex., the Card Element), but requires less effort to maintain. When you want to offer more payment methods, you don’t have to integrate an element for each option.
### What's the cost for using payment element?
The payment element comes at no additional cost to users. The only costs associated are the costs for each payment method they accept (see our pricing info for [local payment methods](https://stripe.com/pricing/local-payment-methods)).
### What APIs are supported by the payment element?
Payment element is supported by CheckoutSessions, PaymentIntents and SetupIntents. Other legacy APIs like Charges and Sources aren't supported.
### Do I need to use webhooks?
Yes, you need to use webhooks with the payment element because server-side confirmation isn’t supported.
However, we're able to support a bypass for this on Payment methods that do not require redirects such as Cards. See the [code for how to do this](https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-redirect).
### How do I use the payment element to offer all the payment methods Stripe supports?
To use the payment element to offer all the payment methods Stripe supports, you can pass an array of payment methods to `payment_method_types` when you create a PaymentIntent. However, you can’t pass all supported payment methods at the same time because some payment methods require different currencies. You can only create a PaymentIntent with payment methods that support the same currency. See the [Payment method and product support table](https://stripe.com/docs/payments/payment-methods/integration-options).
### What is the in-app payment element? How does it compare to the payment element?
The in-app payment element, or Payment Sheet class in code, is a secure pre-built UI component that displays multiple payment methods from around the globe (Cards, Wallets, Bank Debits, Bank Redirects, BNPL, etc). It's similar to the payment element on [web](https://stripe.com/docs/payments/payment-element), but for use within mobile apps. The payment interface presents as a "bottom sheet" (similar to Apple/Google Pay) and is built into Stripe's Mobile SDK. This product will help Stripe merchants increase conversion and reduce payments cost, while moving Stripe’s company goals around non-card payment method adoption. See [our docs](https://stripe.com/docs/payments/accept-a-payment?platform=ios) for more info.