Accept a Payment Stripe Samples

This project provides multiple server-side implementations for handling Checkout Sessions. You can choose an implementation based on your preferred backend language and framework. Each implementation demonstrates how to create a Checkout Session on the server and handle the resulting payment flow.

Available implementations:
- Node (Express)
- Python (Flask)
- Ruby (Sinatra)
- PHP
- Java (Spark)
- Go
- .NET (ASP.NET Core)

This sample demonstrates how to accept payments using the ui_mode: 'elements' configuration for Checkout Sessions.

Workflow:

1. A Checkout Session is created on your server.
2. The server passes the session's client_secret to the frontend.
3. Stripe Elements uses that secret to render a secure payment form directly in your application.

Playwright tests in this project use visual regression testing. If a test fails, it is because the current screenshot differs from the expected screenshot stored in the *-snapshots/ directory.

When a failure occurs in CI, you can inspect the following artifacts from the CI run page:

• The expected screenshot: The baseline image.
• The actual screenshot: The image captured during the current run.
• The visual diff: An image highlighting the differences.

To update the baseline images locally, use the --update-snapshots option with the Playwright command.

Since many payment methods (like bank transfers) are asynchronous, you should implement a webhook handler to automate fulfillment (e.g., updating databases, sending emails, or shipping products).

When receiving a webhook event, you can access the PaymentIntent data via event.data.object. Common event types to monitor include payment_intent.created and various status-related events.

To test webhooks locally without tunneling software like ngrok, use the Stripe CLI with the listen command. This creates a direct connection from Stripe to your local development server.

# Listen for webhooks locally
stripe listen --forward-to localhost:4242/webhook

Instead of hard-coding your Stripe publishable key in your frontend or mobile application, create a helper endpoint (e.g., /get_config) that returns the key.

This is a best practice for mobile clients because it allows you to rotate API keys without requiring users to install a new version of the app.

For Alipay's app-to-app redirect to work, your iOS app must have a custom URL scheme configured. This allows the Alipay app to trigger a redirect back into your application after the user authenticates the payment.

In the provided example, the custom URL scheme is configured as: accept-a-payment://safepay

Ensure this scheme is registered in your project's Info.plist under URL Types.

Instead of hard-coding your Stripe publishable_key in client-side code (especially in mobile apps), implement a simple GET endpoint (e.g., /config) that returns the key.

Why this is a best practice: If you need to rotate your API keys, you can update the key on your server. Mobile apps will fetch the new key on their next request, avoiding the need for users to download an app update to receive new credentials.

The confirmCardPayment method is a high-level function provided by Stripe.js that performs several critical actions in a single call:

1. Tokenization: It sends the raw card details directly from the client to the Stripe API to create a payment method.
2. Confirmation: It attempts to confirm the PaymentIntent using that payment method.
3. SCA Handling: If the payment requires Secure Customer Authentication (SCA), confirmCardPayment automatically handles the user experience by opening a modal or redirecting the user to complete the authentication step.

It resolves with either a paymentIntent object (on success) or an error object (on failure).