What is PayPal Checkout?

How a standard checkout flow works

The visible button is only the beginning of the flow. PayPal's integration documentation separates the customer-facing experience from the server-side steps used to create and complete an order. In a typical one-time purchase, the sequence looks like this:

1. The business prepares the order. Its website or application identifies the items or services being purchased and calculates the order details in the business's trusted system.
2. The server creates a PayPal order. PayPal's Orders API returns an order identifier that connects the checkout session with that order.
3. The customer reviews and approves. The PayPal interface presents the payment experience and lets the customer choose from the options that are eligible for that checkout.
4. The business captures the approved order. After customer approval, the merchant's server requests capture and receives a response that must be checked before fulfillment.
5. Both systems retain matching references. The business associates its internal order number with the PayPal order and transaction information for service and reconciliation.

This summary explains the general pattern documented for PayPal Standard Checkout. It is not a substitute for the current integration guide, because implementation choices, supported features, and account requirements can change.

What the customer may see

PayPal describes Standard Checkout as a way to present payment buttons to a payer. PayPal is one possible funding path, while additional methods may appear when the integration and transaction are eligible. A merchant should not assume that every customer will see the same set of buttons. Availability can depend on country, currency, device, buyer context, merchant configuration, and PayPal's current product rules.

The customer experience may keep part of the checkout on the merchant's site while using PayPal-controlled components for payment selection and approval. The business should make the transition understandable: the order total, merchant identity, return path, and confirmation state should be clear. Button styling and placement should follow PayPal's current documentation rather than being altered in a way that makes the payment option confusing or misleading.

What the merchant remains responsible for

Adding PayPal Checkout does not replace the merchant's own order-management work. The business determines what is being sold, validates the cart or invoice information, calculates the amount in a trusted environment, and decides when a completed payment is ready for fulfillment. It should treat a browser redirect or a success message as part of the customer experience, not as the sole proof that a payment completed.

• Order accuracy: Recalculate trusted order details on the server instead of accepting a customer-editable amount without validation.
• Completion checks: Examine the capture response and the merchant's current PayPal records before shipping goods, delivering access, or marking an invoice paid.
• Error and cancellation paths: Give customers a clear result when they cancel, close the payment window, or encounter an error.
• Record matching: Store the business's order identifier with the relevant PayPal identifiers so staff can research a transaction without relying on a customer's memory.
• Ongoing maintenance: Review PayPal's current SDK and integration documentation when implementing or updating the checkout.

How PayPal Checkout differs from a payment link

A website checkout is normally connected to the site's cart, order, or application flow. PayPal's documented Standard Checkout approach uses client-side components plus server-side order actions. A payment link, by contrast, is commonly a shareable route that takes a customer to a hosted payment experience without requiring the same cart integration. Both can lead to an online payment, but they solve different workflow needs.

A merchant choosing between them should start with the sales process. An ecommerce cart may need item-level order context and an integrated confirmation flow. A simple remote request may be better suited to a hosted link or invoice product. This page does not claim that one option is universally better, and it does not establish which products are available for a particular account. The responsible next step is to map the required workflow and compare it with current provider documentation.

A practical evaluation checklist

Before implementation, document how the proposed checkout will interact with the rest of the business. A short review can prevent the payment button from becoming disconnected from inventory, fulfillment, customer support, or accounting processes.

1. Define the transaction. Identify whether the flow is a one-time purchase, a recurring arrangement, an invoice, or another payment scenario.
2. List the required order details. Note the currency, amount, tax and shipping inputs supplied by the business's existing systems without making assumptions about provider support.
3. Plan the customer journey. Decide where the button appears, how cancellation works, and what confirmation the customer receives.
4. Plan server-side verification. Define how the application creates the order, captures it, handles an unsuccessful response, and prevents duplicate fulfillment.
5. Test realistic outcomes. Use the provider's sandbox and current test guidance for approval, cancellation, error, and repeat-submission scenarios before going live.
6. Prepare support records. Make sure authorized staff can locate a purchase using internal and provider transaction identifiers without collecting unnecessary payment information.

Privacy-safe support and implementation

Keep secret credentials on the server and outside browser code, screenshots, tickets, chat messages, and general contact forms. PayPal's developer documentation distinguishes a client ID from the client secret and instructs developers to keep the secret safe. Access to production credentials and payment records should be limited to assigned staff and approved systems.

Customer support should ask only for the minimum information needed to locate an order, such as the business's order number, transaction reference, date, amount, and masked payment details already available through an approved system. Do not ask a customer to submit a full card number, security code, password, bank credential, or secret API key through a general form. For a PayPal-account issue or a provider-specific transaction status, direct the customer or merchant to PayPal's official account support and records.

Related online payment guidance

Start with the digital wallets and alternative payments FAQ hub for related terminology. Review how merchants accept digital wallets online, read the plain-language guide to digital wallets, or explore the broader ecommerce and online payments FAQ hub. These resources help a business map the checkout experience before comparing a specific provider's current implementation requirements.