Charge a card
Submits the token or session produced by the hosted fields, together with the browser details the issuer needs for 3-D Secure.
The call returns HTTP 201 with an outer status of success even when the card is declined, because the call itself worked. The outcome is data.status:
data.status | What to do |
|---|---|
fingerprint_required | Inject data.fingerprintHtml into a hidden iframe, wait for device data (or about 12 seconds), then call authenticate. |
3ds_required | Inject data.threeDsHtml into an on-page frame of roughly 390 by 400 pixels so the customer can complete the issuer challenge. |
processing | Do not fulfil. Wait for the checkout event or the webhook, or poll verify. |
success | The processor reports the payment as paid. Show a receipt, then confirm with verify on your server. |
failed | Show data.message. Offer another card, with a new card session. |
Run the 3-D Secure challenge in an on-page iframe. Do not use a pop-up window. Each payment allows a limited number of charge attempts. When they run out the call fails with payment.max_attempts_exceeded and you must initialise a new payment.
On the sandbox mock processor, 4111111111111111 and 4242424242424242 succeed and any other number is rejected. When CyberSource or MPGS is the active test processor, use that processor’s own test cards.
Authorizations
The accessCode returned by initialise. Scoped to one payment and valid for 60 minutes.
Safe to give to the customer's browser.
Body
The card token or session, and the browser details the issuer uses to assess risk.
The CyberSource token returned by the microform, or the MPGS session ID. If you send neither this nor transientToken, Vestrapay uses the token stored when the session was created.
An alias of sessionId for CyberSource.
The browser user agent string.
Read these from the real browser. Accurate values help the issuer approve the payment.