> ## Documentation Index
> Fetch the complete documentation index at: https://docs.payments.bob.company/llms.txt
> Use this file to discover all available pages before exploring further.
# Credit card
> Accept credit cards through Bob's hosted checkout or embeddable SDK.
**Coming soon.** Credit card payments are not available on Bob yet. This page describes how it will work once it launches — for now, use **PIX**.
Bob Payments will also process **credit cards**. For most integrations, you'll use Bob's hosted checkout or embeddable SDK. They load the secure fields, tokenize the card, run 3DS, and handle processing internally.
To accept cards at checkout, the card **must be tokenized in the browser** by Bob's checkout package (`@bobpayments/checkout-sdk`). Your application and the API only receive a secure token — PAN, CVV, and expiration date never pass through the Bob API. See the [Checkout SDK](/en/pages/sdk/checkout) and the [Reference](/en/pages/credit-card/reference).
## Choose the integration level
| Level | When to use |
| ------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Hosted checkout** | The default path. You create a session and redirect the buyer to the `checkoutUrl`. |
| **Embeddable SDK** | Use it when you already have your own page and want to build Bob's checkout inside it. |
| **Direct API** | Use it only for advanced integrations that already have their own tokenization, compliance, and 3DS handling. |
## Recommended flow
```text theme={"system"}
Card
-> Bob Checkout or @bobpayments/checkout-sdk
-> secure tokenization
-> Bob API
-> Bob's internal processing
```
The card number, CVV, and expiration date never pass through the Bob API. The buyer doesn't see any internal processing details.
Never send raw card data to the Bob API. Payloads containing PAN, CVV, or expiration date must continue to be rejected.
## Hosted checkout
To accept cards at the hosted checkout, send `credit_card` in `paymentMethods`:
```bash theme={"system"}
curl -X POST https://api.payments.bob.company/api/v1/checkout-sessions/ \
-H "Authorization: Bearer $BOB_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amountCents": 25000,
"items": [{ "name": "Pro Subscription", "quantity": 1, "unitAmountCents": 25000 }],
"paymentMethods": ["credit_card", "pix"],
"successUrl": "https://store.example.com/thank-you",
"webhookUrl": "https://store.example.com/webhooks/bob",
"webhookVersion": "v2"
}'
```
The session accepts `credit_card` when the method is enabled on the project. Otherwise, the API reports that the method is not available.
## Embeddable SDK
Use the embeddable SDK when you want to keep the buyer on your site but don't want to implement the secure fields, tokenization, 3DS, or fallback.
```tsx theme={"system"}
import { BobCheckout } from '@bobpayments/checkout-sdk';
navigate(`/orders/${payment.id}`)}
onError={(error) => showError(error)}
/>
```
Or mount the checkout on a page without React:
```typescript theme={"system"}
const checkout = await BobCheckout.create({
sessionToken: checkoutToken,
});
checkout.mount('#bob-payment');
```
The SDK handles the secure fields, creates a secure payment method identifier, sends the token to the Bob API, and runs 3DS when needed. The merchant doesn't need to import any additional libraries.
See how to embed Bob's checkout on your site.
## Advanced direct API
Use the direct API with cards only when you already have your own tokenization and 3DS authentication implementation. In this mode, the frontend creates a secure payment method identifier (`pm_...`) and sends Bob only that token, along with `paymentMethod: "credit_card"`.
The `pm_...` should exist only in memory during the attempt. Don't store this value in logs, analytics, the URL, or the checkout database.
## Processing and fallback
For cards, Bob manages retries and fallback internally. The buyer receives a single final response and doesn't see any processing details.
When the payment requires action from the buyer, such as 3DS authentication, the checkout must show the secure authentication, open the returned URL, and query the status on return. Show success only when the session or transaction is `PAID`/`paid`.
## Public states
| Status | Meaning |
| ----------------- | -------------------------------------------------------- |
| `paid` | Payment approved |
| `waiting_payment` | Awaiting 3DS authentication or asynchronous confirmation |
| `failed` | Processing was not completed |
| `pending` | Payment created, but still without final confirmation |
Use webhooks and/or status queries to confirm the financial outcome. Don't treat an HTTP `201` alone as payment confirmation.
## What you configure
On your side, configuration is done through the Dashboard:
1. Enable cards for the project, when needed.
2. Use the hosted checkout or the Checkout SDK to collect the card.
3. Configure Bob's webhook to receive the payment confirmation.
Bob manages card processing, reconciliation, and the internal details of the operation. You don't need to send payment provider credentials to your application.
Never send secret credentials or raw card data to the browser, to the Bob API, or to repositories.
## Next steps
Tokenize the card in the browser and embed the checkout on your site.
Structure and attributes of a card transaction in the API.