Charging a card consists of three steps:
🕵️ Authentication - Card information is sent to the card issuer for verification. Some cards may require the cardholder to strongly authenticate the purchase through protocols like 3D Secure.
💁 Authorization - Funds from the customer's account are put on hold but not transferred to the merchant.
💸 Capture - Funds are transferred to the merchant's account and the payment is complete.
The Payment Intents API abstracts away these three stages by handling all steps of the process through the confirm method. After you create a PaymentIntent, call confirm to authenticate, authorize, and capture the funds in one API call.
There are two implementations depending on whether you want to use webhooks for any post-payment process:
- /using-webhooks Confirms the payment on the client and requires using webhooks or other async event handlers for any post-payment logic (e.g. sending email receipts, fulfilling orders).
- /without-webhooks Confirms the payment on the server and allows you to run any post-payment logic right after.
This sample shows:
| Using webhooks | Without webhooks | |
|---|---|---|
| 💳 Collecting card and cardholder details. Both integrations use the card Element from our mobile SDKs to build a custom checkout form. | ✅ | ✅ |
| 🙅 Handling card authentication requests and declines. Attempts to charge a card can fail if the bank declines the purchase or requests additional authentication. | ✅ | ✅ |
| ↪️ Using webhooks to respond to a hold being placed on the card. Confirming the payment on the client requires using webhooks for any follow up actions, like emailing a receipt. | ✅ | ❌ |
| 🏦 Easily scalable to other payment methods. Webhooks enable easy adoption of other asynchroneous payment methods like direct debits and push-based payment flows. | ✅ | ❌ |
This sample includes 5 server implementations in Node, Ruby, Python, Java, and PHP for the two integration types: using-webhooks and without-webhooks. For each integration type, there are 4 mobile client implementations, in Swift (iOS), Objective-C (iOS), Kotlin (Android), and Java (Android).
To run a sample server locally, first copy the .env.example file to your own .env file:
cp .env.example .env
You will need a Stripe account with its own set of API keys. Enter your Stripe secret API key in the .env file.
Then, choose a sample server, and follow the instructions in the server's README to run locally.
Next, choose a client app, and follow the instruction in the app's README to run.
When the app is running, use 4242424242424242 as a test card number with any CVC code + a future expiration date.
Use the 4000000000003220 test card number to trigger a 3D Secure challenge flow.
Read more about testing on Stripe at https://stripe.com/docs/testing.
Q: Why did you pick these frameworks?
A: We chose the most minimal framework to convey the key Stripe calls and concepts you need to understand. These demos are meant as an educational tool that helps you roadmap how to integrate Stripe within your own system independent of the framework.
Q: Can you show me how to build X?
A: We are always looking for new sample ideas, please email dev-samples@stripe.com with your suggestion!