{"id":16470,"date":"2024-06-27T15:08:38","date_gmt":"2024-06-27T13:08:38","guid":{"rendered":"https:\/\/docs.centralpay.com\/documentation\/3ds-2-2-authentication\/transaction-initiated-by-the-holder-cit-brw\/"},"modified":"2026-08-20T17:09:08","modified_gmt":"2026-08-20T15:09:08","slug":"transaction-initiated-by-the-holder-cit-brw","status":"publish","type":"docs","link":"https:\/\/docs.centralpay.com\/en\/documentation\/3ds-2-2-authentication\/transaction-initiated-by-the-holder-cit-brw\/","title":{"rendered":"Transaction Initiated by the Holder (CIT \u2013 BRW)"},"content":{"rendered":"\n

The BRW<\/strong> (Browser) flow applies to Customer-Initiated Transactions (CIT)<\/strong>: the cardholder is present and authorizes the payment personally. This authenticated CIT also serves as the foundation for future MIT transactions. <\/p>\n\n

\ud83d\udc49 For a transaction initiated by the merchant without<\/em> the cardholder (recurring billing, variable amounts, usage-based charges, one-time fees), see the 3RI flow documentation<\/a>.<\/p>\n\n

\u274c Be careful when choosing the payment flow:<\/strong> Using BRW for a merchant-initiated transaction (MIT) results in non-compliance, unnecessary friction, and a significant drop in the conversion rate.<\/pre>\n\n
1. The main steps in the BRW workflow<\/h2>\n\n
The BRW flow consists of five steps on the API side, two of which are conditional: versioning<\/strong> (is the card authenticatable?) \u2192 3DS Method<\/strong> (if necessary)<\/em> \u2192 authentication<\/strong> \u2192 challenge<\/strong> (if required by the bank)<\/em> \u2192 result<\/strong>, before completing the transaction<\/strong>.<\/p>\n\n
\"3DS<\/figure>\n\n
\u2139\ufe0f The entire process must take place on a single web page<\/strong>, without being redirected to a bank page, using an iframe solution. This is a requirement of the banking process. <\/pre>\n\n
To speed up your integration of the BRW flow, you can start with a complete sample application (PHP\/Twig) that replicates the entire sequence described on this page: CUSTOM payment form, versioning<\/em>, 3DS Method in an iframe, authentication<\/em>, challenge handling, results<\/em>, and then the transaction, <\/em>all on a single page, in accordance with banking requirements.<\/p>\n\n
\ud83d\udc49 Download the sample code<\/a> \u00b7 View the online demo<\/a><\/p>\n\n
Before running the sample code, enter your credentials in the file .env<\/code>  (API_USER<\/code>,  API_PASSWORD<\/code>,  POS_UUID<\/code>) and point it HOST_CENTRALPAY_API_CORE<\/code> to the test environment https:\/\/test-api.centralpay.net\/v2\/rest\/<\/code>.<\/pre>\n\n
2. Versioning<\/h2>\n\n
The versioning<\/em> is the first step: it queries the card network to determine whether the card can be authenticated using 3DS 2.2, and retrieves the technical information needed for the rest of the process. Specifically, you send the card\u2019s PAN<\/strong> (Primary Account Number<\/em>, the 16-digit number) to the CentralPay API. <\/p>\n\n
Sample (curl) :<\/strong><\/p>\n\n
curl --location --request POST 'https:\/\/test-api.centralpay.net\/v2\/rest\/3ds2\/versioning' \\\n--header 'Content-Type: application\/x-www-form-urlencoded' \\\n--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \\\n--data-urlencode 'acctNumber=4000001000000067'\n<\/code><\/pre>\n\n
Understanding the response<\/strong>. A card is said to be \u201cenrolled<\/strong>\u201d when the bank that issued it participates in the 3DS 2.2 protocol for that card. This is determined by the issuing bank: neither you nor CentralPay can enroll a card. Versioning<\/em> is used precisely to determine whether this is the case.  <\/p>\n\n