ASP.NET Web API Help Page

Introduction

This Payments API supports the Fiserv PaymentJS flow for card tokenization and payment. The typical sequence is: call AuthorizeSession to obtain a client token and public key; load the PaymentJS SDK and tokenize the card on the client; Fiserv POSTs the tokenization result to the Webhook endpoint; the client then calls ProcessTokenizedPayment to complete or continue the payment (including 3D Secure when required).

For 3D Secure: ThreeDSNotification receives the method form callback from Fiserv's ACS; ThreeDSComplete handles the challenge completion redirect (cRes). The TermUrl query uses MAC parameter termMac (legacy t); the method notification URL uses methodMac (legacy m; legacy sessions may still use bookingId and bookingHash on TermUrl until retired). If the ACS method notification is slow, the server sends EXPECTED_BUT_NOT_RECEIVED to Fiserv automatically while the client polls ProcessTokenizedPayment (see MethodNotReceivedTimeoutSeconds in fiserv.config)â€”there is no separate notify endpoint. ProcessTokenizedPayment has many possible response shapes (errors, still processing, already approved, 3DS challenge or method form, approved, failed, status). The API detail page for ProcessTokenizedPayment includes an "Additional information" section with the full list of response shapes.

PaymentJS

PaymentJS API: Fiserv card tokenization and payment flow. Typical flow: call AuthorizeSession to obtain a client token and public key; the client uses PaymentJS to tokenize the card; Fiserv POSTs the result to Webhook; the client then calls ProcessTokenizedPayment to complete or continue the payment (including 3D Secure). 3DS endpoints: ThreeDSNotification (method form callback), ThreeDSComplete (challenge redirect with cRes; TermUrl query uses MAC termMac or legacy t, or legacy bookingId/bookingHash). Method-not-received timeout is handled server-side in ProcessTokenizedPayment.

API	Description
POST api/PaymentJS/AuthorizeSession	Obtains a client token and public key for PaymentJS card tokenization. Request must include BookingId (or BookingID) and SuccessUrl. Response includes PaymentJSSdkUrl, ClientToken, and PublicKeyBase64 when successful. Blocks duplicate active sessions per order; only one AuthorizeSession can be in progress per booking at a time.
POST api/PaymentJS/AbandonSession	Marks an in-progress PaymentJS session as abandoned so the customer can Place Order or AuthorizeSession again (e.g. Back to Terms).
POST api/PaymentJS/ThreeDSComplete?transactionId={transactionId}&termMac={termMac}&t={t}&bookingId={bookingId}&bookingHash={bookingHash}	Handles 3D Secure challenge completion redirect from ACS. Receives cRes in the POST body (application/x-www-form-urlencoded). Query: transactionId (FiServ_OrderID) plus either Term MAC (query name termMac, legacy t) or legacy and .
POST api/PaymentJS/ProcessTokenizedPayment	Completes or continues a payment using the tokenized card. Called by the client after PaymentJS tokenization (once the webhook has delivered the token). Request: bookingId (or BookingID) and clientToken from AuthorizeSession. Idempotent: may return already-approved, 3DS challenge, or current status without submitting again. Possible outcome categories: validation/resolution errors (e.g. invalid bookingId, session mismatch, tokenization failed); still processing (webhook pending); already approved; 3DS challenge required (challengeUrl, threeDSFormFields); 3DS method form required (threeDSMethodFormHtml); payment approved (redirectUrl, bookingID); payment failed; existing transaction status (e.g. WAITING_3DS). See remarks for full response shapes.

Status

Endpoints for retrieving system status and configuration information. Refactored to use service layer with dependency injection.

API	Description
GET api/Status	Returns current system status including booking availability, call center hours, and maintenance warnings.