Hyperswitch external 3DS authentication with Netcetera and other 3DS servers

The authentication result is the hand-off between two separate steps. In a standalone setup, the payment is created with request_external_three_ds_authentication set, which tells Hyperswitch to run cardholder authentication through the selected external provider before the payment moves on to authorization. The provider, whether Netcetera, GPayments, 3dsecure.io or the Juspay 3DS Server, decides the outcome of that check and returns it to Hyperswitch. Authorization is then a separate request that carries the outcome forward to a processor. Keep this model in view when you compare it with processor-managed 3DS, where the authentication call goes to the processor and no separate provider result is handed back.

From the cardholder's side, the check either completes without interaction or stops for a challenge. In a frictionless flow, the provider's data collection and risk assessment finish in the background and the payment continues without a prompt. In a challenge flow, the cardholder completes a step the issuer requires, such as entering a one-time code or approving in an app, and then returns to your checkout or app. Your team needs to design the return path for both cases, including what the shopper sees if the challenge is abandoned, times out or fails. Confirm with the provider and your front-end integration which events signal completion, so the page does not wait indefinitely or submit the payment before a result exists.

From the system's side, the result is stored against the payment before authorization runs. Routing then selects the processor, and processor eligibility still decides where the payment goes. Hyperswitch's routing strategies include default fallback routing for when no rule applies or a processor is ineligible, which means a payment can reach a processor that did not expect the authentication result it received. Before go-live, ask each processor in your routing plan which authentication outcomes it accepts, which authentication data elements it needs in the authorization request, and how it treats a payment where authentication failed, was attempted or could not be completed. Record those answers as explicit routing constraints.

Treat each possible outcome as a design decision with a named owner. Map every result your provider can return to one of three paths: authorize with the result, decline, or route to a processor that accepts that result. Decide whether a failed or unavailable authentication blocks the payment or continues under a risk position your fraud and compliance teams have accepted in writing, and document that choice before build. If you use fallback routing, test the fallback path explicitly, because a payment that succeeds on the primary processor may be sent to a fallback processor that handles the same outcome differently. Log the authentication outcome and the chosen processor on each payment so support and reconciliation can trace every decision.

Do not sign off the design until you have run each path in the provider's sandbox. The docs list Netcetera with sandbox integration status and the Juspay 3DS Server with alpha status, so plan more verification for the Juspay option and confirm its result handling directly with Juspay before you depend on it. Exact result handling for each provider, including which fields are returned and how timeouts appear, should be confirmed in the provider's sandbox before you rely on general 3DS behavior. Test frictionless success, challenge success, challenge failure, abandonment and provider unavailability, and check that each one produces the payment state and processor path you documented.

Start with a sandbox run for each external 3DS provider before any live cardholder traffic reaches the standalone flow. For each provider, send test payments with request_external_three_ds_authentication set on the payment, and confirm that authentication runs as a separate step from authorization. Cover the frictionless and challenge outcomes wherever the provider's test cases allow. Not every provider exposes every outcome in sandbox, so record which outcomes you reproduced and which you could not. Netcetera is listed with sandbox integration status, while the Juspay 3DS Server is listed as alpha. Confirm with each vendor whether its sandbox fits the scope you plan to launch before you rely on it for sign-off.

Next, test the paths where authentication does not complete cleanly. Simulate a failed authentication and a timed-out authentication, and confirm with the provider how each is triggered in its sandbox. For each case, record what the router returns to the caller, whether the payment is declined, retried or left pending, and whether the merchant receives a clear status. Certificate handling needs its own cases. Netcetera authenticates with a PEM certificate and matching private key for mutual TLS, so test what happens when the certificate is past its expiry date. Also test a rotated key pair end to end, including whether old and new material can overlap during cutover. Confirm that expiry alerts exist and fire before the certificate lapses.

Then test processor authorization after each authentication outcome. After a successful authentication, confirm that the authorization request carries the authentication result the processor expects and that the payment completes. After an unsuccessful authentication, confirm that the flow follows the decision your policy sets, and that no authorization is sent when that policy calls for stopping. Test card numbers, expected authentication results and the processor's behavior for each case must come from the provider and the processor themselves. Do not build test cases from public lists or assumptions. Ask the processor which 3DS data fields it accepts from a standalone provider, and check those fields in the request logs.

Finally, check observability before go live. Logs, the Control Center and any dashboards should show the authentication outcome, the provider and the payment reference, so an operator can tell whether a decline came from authentication or from the processor. Verify that those surfaces never show a full card number, cryptographic values, the private key or certificate private material, and that router log levels do not expand request bodies. Keep a written test record for your own compliance evidence. Include the test case ID, provider, environment and software version, expected result, actual result, evidence location and the name of the person who signed off. This record supports assessment preparation, but it does not replace review by an independent auditor.