Skip to main content
Kibo commerce APIs never take a raw card number. Before you save a card to a customer account or apply a card payment to a checkout or order, you send the card details to the Kibo payment service on the PCI payments host. The payment service stores the card and returns a card ID. You then use that ID, called paymentServiceCardId, in every other API call. This keeps card data off your servers and out of the commerce APIs, which reduces your PCI DSS scope. For background on how payments work in Kibo, see Payments: A Conceptual Guide.

How It Works

  1. The shopper enters card details in your checkout or account page.
  2. The shopper’s browser sends the details directly to the PCI payments host.
  3. The payment service returns a card id and a masked card number, numberPart.
  4. Your storefront sends the id as paymentServiceCardId, with numberPart, to the commerce APIs:
    • to save the card to a customer account, or
    • to pay for a checkout or order.
Call the card endpoint from the shopper’s browser. Do not send card numbers or CVVs through your own servers, and do not log or store them. Only the returned id and numberPart should reach your application.

The PCI Payments Host

Card requests go to the PCI payments host, not to your tenant host. This is the same host you set as pciHost in the TypeScript SDK or as KIBO_PCI_HOST in the Nuxt.js storefront. For example, a sandbox tenant at https://t1000000.sb.usc1.gcp.kibocommerce.com uses the PCI payments host https://payments-sb.usc1.gcp.kibocommerce.com. If you do not know the PCI payments host for your environment, contact Kibo Support. The card endpoints are: Send your tenant ID in the x-vol-tenant header and your site ID in the x-vol-site header. These requests do not take an access token, so the shopper’s browser can call them without your application credentials.

Create a Card

Send the card details in the request body.
For VISA, MC, AMEX, DISCOVER, and JCB cards, the payment service checks the card number and expiration date before it stores the card. An invalid card returns an error. A successful request returns 200 OK:
Keep both id and numberPart. The commerce APIs need both to identify the card, and the payment service needs numberPart when it authorizes a payment.

Save the Card to a Customer Account

To let a shopper reuse the card, add it to their account with Add Account Card (POST /api/commerce/customer/accounts/{accountId}/cards). Set the card id to the paymentServiceCardId.
contactId is the ID of the billing contact on the customer account. For a full example, see Add a Saved Credit Card in the Customer API developer guide.

Pay with the Card

To pay for a checkout or an order, create a payment action with a CreatePayment action name. Use Create Payment Action for a checkout or Create Payment Action for an order. Put the card in newBillingInfo.card:
Set cardNumberPartOrMask to the numberPart value from the create response. For a card saved on the customer account, use the account card’s id and cardNumberPart. For every field in billingInfo, see Payment Types API Reference.

Update a Card

To change a stored card, such as a new expiration date, send PUT to the card’s ID with the fields you want to change. Fields you leave out keep their current values. Always include cardNumber: to keep the stored number, send the masked numberPart from the create response.
The response has the same fields as the create response. The id does not change. If the card is saved to a customer account, also update the account card with Update Account Card so the account shows the same details.

Delete a Card

To remove a card from the payment service, send DELETE to the card’s ID. A successful request returns 204 No Content.
If the card is saved to a customer account, remove it from the account with Delete Account Card.