WooCommerce RedSys Gateway v31.0.3

Decryption key:

To view the content, you need to Sign In or Register.

WooCommerce RedSys Gateway v31.0.3
*** Redsys Gateway Change Log ***

2026.06.27 - version 31.0.3

* SECURITY: Removed a notification signature-bypass that could let an anonymous request mark an order as paid when the SHA-256 secret was left empty/misconfigured. The Redsys IPN listener (public wc-api endpoint) had a legacy fallback that, when no secret was configured, accepted a notification solely because the posted Ds_MerchantCode matched the merchant FUC - a public, non-secret value an attacker can supply. That merchant-code-only acceptance has been removed from every gateway (Redirection, Bizum, Bizum InSite, Google Pay checkout and redirection, Apple Pay, PayGold, Direct Debit, MasterPass and Bank Transfer): when there is no secret to verify the HMAC, the request now fails closed (HTTP rejection) instead of being trusted. In addition, the shared verification routine (WooRedsysAPI::verify_signature_notif) now returns false whenever the merchant key or the received signature is empty, so neither check_ipn_request_is_valid() nor successful_request() can complete a payment on an attacker-computable empty-key HMAC. InSite already required a valid signature (no merchant-code fallback) and Inespay is unaffected (it matches orders by its own payin id). Real stores are unaffected because a configured secret is mandatory to take payments in the first place.
* NEW: "Apps and Plugins" section under Redsys Advanced -> Redsys Advanced Settings. A read-only landing page that showcases the native macOS management app (with download, requirements and "coming soon" platforms) and lists the rest of the free and premium plugins, websites and portals, Claude skills and developer profiles by José Conti, each grouped by type with a link. Every list is filterable (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
* FIX: Bizum notifications were rejected with a signature verification error, leaving the order unpaid even though the payment had been authorized at Redsys. The merchant key and the order number were correct (the request signature matched perfectly), but the notification signature is an HMAC computed over the Ds_MerchantParameters string exactly as received, and Bizum notifications arrive with the trailing base64 "=" padding stripped while Redsys signs over the canonically padded value, so the locally computed HMAC never matched. The shared notification routine (create_merchant_signature_notif in WooRedsysAPI) now re-pads the payload to a multiple of four before hashing, and the verification (verify_signature_notif) now compares both signatures ignoring the trailing "=" padding (which carries no entropy, so the comparison stays constant-time). Card payloads are already canonical and are left untouched, so every other gateway keeps working unchanged. This routine is shared by all notification handlers (Redirection, Bizum, InSite, PayGold, Google Pay, Apple Pay, Direct Debit, Bank Transfer and the REST/A2A clients).
* FIX: Card and wallet notifications could be rejected with a "signature mismatch", so the customer returning to the thank-you page (and the server-to-server IPN) failed to mark the order as paid until a later IPN retry happened to succeed; refunds and PayGold links paid later could stay unconfirmed. Two padding issues are involved: besides the Bizum payload padding above, Redsys delivers the notification signature (Ds_Signature) in URL-safe base64 with the trailing "=" stripped, while the locally computed signature keeps it - so a strict comparison fails for ordinary card payments too. The padding-tolerant comparison lives in verify_signature_notif(), but most handlers were still comparing the signature inline with a strict hash_equals()/!== that re-introduced the sensitivity. Every handler now delegates to verify_signature_notif(), so the fix reaches all of them: card Redirection (both IPN validators and the capture/refund REST-SOAP response checks), Bizum, Bizum InSite, InSite (IPN, successful_request and the two REST-response validators), PayGold, Google Pay (checkout and redirection), Apple Pay, Direct Debit, Bank Transfer, MasterPass and the InSite REST client. Regression introduced when the per-gateway signature checks were unified onto verify_signature_notif() with a strict, padding-sensitive comparison.
* FIX: Bizum notifications on multi-currency / dual-terminal stores (those routing each order to a different terminal through the bizum_modify_data_to_send filter or a conditional rule) now resolve the real per-order signing key before verifying the signature (the customer-adjusted settings key, the transient saved when the payment form was generated, or the _redsys_secretsha256 order meta), and an unverifiable notification is rejected with HTTP 400.
* FIX: InSite card payments that required a 3DS challenge showed a blank verification screen in Safari (iPhone/Mac), so the customer could not enter the SMS code/PIN and the payment failed (the same flow worked in Chrome). The challenge itself was already a full-page, top-level navigation, but before it the plugin redirected the browser to the issuer's 3DS Method URL (threeDSMethodURL) to fingerprint the browser, and Safari's Intelligent Tracking Prevention blocks the third-party cookies that step needs, leaving a blank ACS page (symptom: the ACS URL arrives with ";jsessionidpa=" because the cookies are not flowing). The 3DS Method browser step is optional, so the plugin no longer redirects the browser to threeDSMethodURL: it always sends threeDSCompInd = 'N' and continues straight to authentication. Applied to every InSite flow - new card and saved card (one-click/token), on both block and classic (shortcode) checkouts - and to the Redirection gateway's REST/token flows (pay_with_token_c, receipt_page and successful_request), since the same blank screen could appear when charging a saved-card token.
* FIX: When an InSite card payment failed because a required checkout field was missing or its data did not match (for example an empty surname produced a "signature mismatch"), the error message blamed the card ("...enter your card details again"), so customers thought their card had been rejected and abandoned the order. The message is now neutral and points to the checkout fields first: it asks the customer to check that all the checkout fields (name, surname, address, etc.) and the card details are filled in correctly before trying again. Applied to both the classic and block (Blocks) checkouts.
* FIX: Refunds and delayed payments of orders with large order IDs (the "1 billion bug" already fixed for instant checkout) were recorded against the wrong order, or not recorded at all. The Redsys notification (IPN) recovers the WooCommerce order ID from the order number through clean_order_number(), which first looks up a transient saved when the order number was generated and otherwise fell back to a substr/ltrim heuristic that drops the high-order digits of IDs with 10 or more digits. That transient has a 1h TTL, so the fallback was hit whenever the notification arrives more than an hour after the order number was generated: every refund (processed days or weeks later) and PayGold payment links (paid by the customer later), among others. Three changes make this robust for every payment method: (1) the shared refund routine (ask_for_refund) now re-saves the order-number to real-order-ID mapping at refund time with a 24h TTL; (2) clean_order_number() now, when the transient is gone, reverse-looks up the order by the persisted order-number meta (_payment_order_number_redsys / _redsys_transaction_id2) before ever using the lossy heuristic; and (3) PayGold now persists the order number to meta when the link is created, so a link paid much later still resolves to the exact order. Applies to every gateway (Redirection, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold and Direct Debit). Inespay is unaffected (it matches orders by its own payin id).
* DEV: Removed the noisy debug console.log output from the production (minified) frontend scripts (Apple Pay, Google Pay, capture-order-id and the express-checkout modals). The Apple Pay express script in particular logged on every DOM change (it watches the whole document for its button), which flooded the browser console on the Blocks checkout. The minified files now strip console.log/console.warn/console.info/console.debug while keeping console.error; the un-minified sources are unchanged for development.
* FIX: InSite card payments on the block-based (Blocks) checkout failed the FIRST time with "msg18" (the customer saw "check that the checkout/card fields are filled in") and only worked on the second attempt. The Redsys InSite SDK requires the page to send a "domain" message to the card iframe so Redsys can validate the merchant; the SDK does this through an inline onload="setMerchantDomain(0)" on the iframe. The block script overwrote that handler with its own iframe.onload (used to size the iframe) right after the first render, so the merchant domain was never sent and Redsys rejected the tokenisation with msg18 ("incorrect validation by the commerce"). On the automatic form refresh the overwrite did not run, so the second attempt worked. The plugin now calls setMerchantDomain explicitly after building the form (as the SDK's own pay-button integration does) and no longer overwrites the iframe onload, so the first attempt works.
* FIX/DEV: InSite Blocks checkout - made the Redsys postMessage handling more robust and added end-to-end diagnostics. The handler now accepts messages from any Redsys subdomain (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) instead of requiring an exact host/port match (Redsys posts from more than one host), removes any listener left by a previous render so a single token cannot trigger multiple submissions, and clears the token/error fields after reading them so a stale re-fire cannot resend. When InSite debug logging is enabled, the whole client-side tokenisation step (order number, Redsys postMessage, token/error code, save and place-order) is mirrored into the "insite" WooCommerce log, so first-attempt failures that never reach PHP can be diagnosed.
* FIX: InSite card payments on the block-based (Blocks) checkout were rejected by Redsys with SIS0574 ("EMV3DS authentication operation rejected, browserUserAgent not indicated"): the 3DS browser fingerprint (user agent, screen size, language, colour depth, timezone) never reached the order, because the hook that normally copies it onto the order (woocommerce_checkout_create_order) does not run on the Store API (Blocks) checkout. The InSite Blocks form now collects the fingerprint and sends it together with the operation token, and it is written onto the real order (next to the token) before process_payment runs, so the EMV3DS authentication has the data it needs.
* FIX: InSite card payments on the block-based (Blocks) checkout were rejected with an "error code without token" (shown to the customer as "check that the checkout/card fields are filled in"), so the card could not even be tokenised after a few attempts. Because the order does not exist yet on the Blocks checkout (order id 0), the prepared Redsys order number was generated from id 0, which produced an almost constant value - only ~999 possible numbers, all ending in nine zeros - and Redsys rejects a reused order number ("pedido repetido", SIS0051). When the draft order id is not yet available, the InSite Blocks form now uses the same temporary order number as the InSite shortcode checkout (create_checkout_insite_number: always starts with 1, globally unique through a shared incremental counter), so it never collides; when the draft order id is available, the Redsys number is built from it. The number is re-linked to the real order id when the order is placed.
* FIX: InSite card payments on the block-based (Blocks) checkout failed: the customer saw a misleading "check that the checkout/card fields are filled in" error and the order was never paid (the browser console showed a 404 on the save_order_data request). The cause is that current WooCommerce no longer creates the order until the customer presses "Place order" - during card entry the Blocks checkout store returns order id 0 - so the InSite operation token (idOper) and the prepared Redsys order number could not be persisted: the previous flow posted them to a REST route (save_order_data) that tried to attach them to order 0 and returned "Invalid order" (404), and the generated order number was mapped to order 0 (so even a later notification could not find the order). Now, when the card is tokenised, the token and the prepared order number are stored in the WooCommerce session via admin-ajax (the WC session is not available on custom REST routes, which is why the prior REST approach could not use it), and they are moved onto the real order while WooCommerce is creating it from the checkout request (woocommerce_store_api_checkout_update_order_from_request), before process_payment runs, so process_payment_block() finds _insite_token and _payment_order_number_redsys as it does on the classic checkout. The order-number transient is also re-mapped to the real order id so the notification (IPN) resolves the order. The browser-fingerprint (3DS) data already used this same session route. The classic/shortcode checkout is unaffected.

Decryption key:

To view the content, you need to Sign In or Register.

WooCommerce RedSys Gateway v31.0.2
Version 31.0.2Released on 2026.06.16

• The redsys_modify_data_to_send filter now receives 'context' => 'add_payment_method' and 'user_id' in the data array for the "Add payment method" flow, so custom snippets and conditional rules can route the tokenization to the right terminal (terminal + SHA256) without relying on an order that does not exist in this flow.
• Adding a card from My Account ("Add payment method") on multicurrency stores could be rejected by Redsys with a currency error. The request was sent with the customer's session currency (e.g. ARS, 32) but the default terminal, which is configured for another currency (e.g. EUR, 978). Card tokenization is a zero-amount operation with no order behind it, so if no filter or conditional rule routes the request to another terminal, the store base currency is now sent, always matching the default terminal configuration.
• Adding a card from My Account (or via the profile email link) always registered the card at Redsys as one-click (DS_MERCHANT_COF_TYPE 'C'), even when the customer selected the subscriptions option. The token type was read from the wrong internal key, so 'R' was never sent. The token was stored correctly as R in WooCommerce, but the COF agreement was created as C at Redsys, which could cause some issuers to decline later subscription renewals (MIT) made with those tokens. Cards added with the subscriptions option now correctly send DS_MERCHANT_COF_TYPE 'R'. Tokens created while the bug was present cannot be reclassified; if a renewal is declined, ask the customer to re-add the card.
• Payments made with a saved card (token R) and subscription renewals did not honor the preauthorization settings. With "Preauthorize all orders" enabled (or a product marked for preauthorization), the charge was executed as a regular sale (type 0) but the order was still marked as "Preauthorized", so confirming the preauthorization later failed at Redsys with SIS0059 ("No operation exists on which to perform the confirmation"). Both flows now send a real type 1 preauthorization that can be confirmed later, and an order is only marked as "Preauthorized" when a real preauthorization was executed. This also enables preauthorized subscription renewals (for example goods sold by weight, where each renewal is adjusted before the final charge).
• Updated all translations.
• The merchant SHA-256 secret key is no longer written in plain text to the WooCommerce debug logs. All debug entries now mask the key, showing only its last 4 characters, via the new WCRed()->mask_secret() helper. Applied across all gateways (Redirection, InSite, Bizum, Google Pay, Apple Pay, PayGold, Direct Debit and the Blocks support classes).
• Redsys notification (IPN) signatures are now verified with hash_equals() (constant-time comparison) in all notification handlers, unifying them with the verification already used by InSite and the REST client. Hardening against timing attacks.
• The single-token delete AJAX handler in the tokens management screen now requires the manage_woocommerce capability in addition to the nonce, matching the bulk-delete handler.

WooCommerce RedSys Gateway v31.0.1
Versione 31.0.1Released on 2026.06.09

• Bizum on the payment page (Bizum InSite) did not send the description to Redsys. The actual charge from the modal is made through the REST API (trataPeticionREST), and that request did not include the DS_MERCHANT_PRODUCTDESCRIPTION parameter, so the configured "Redsys Description" (for example "Order ID") reached the Redsys panel empty. The description is now computed from the selected setting and sent in the REST request.
• The countdown in the Bizum payment-page modal showed 7 minutes. It now correctly shows 5 minutes, and the server-side time control that redirects to the checkout has been adjusted accordingly (60 iterations * 5 seconds = 5 minutes).

WooCommerce RedSys Gateway v30.4.1
Version 30.4.1Released on 2026.05.05

• "Redsys email to customer" toggle in Redsys Advanced Settings → General to control whether DS_MERCHANT_EMAIL_TITULAR is sent to Redsys. When enabled and the Redsys terminal is configured to notify customers, Redsys sends its own purchase confirmation email to the buyer. Disabled by default — WooCommerce already sends its own order email, so existing installations stop forwarding the customer email to Redsys after the update. Applied to both Redsys Redirection and InSite gateways (classic and Blocks checkouts).
• Apple Pay Express button on the product page failed to open the payment sheet on iOS Safari mobile when the Express custom fields feature was enabled. The pre-payment AJAX call (modal lookup or modal save) ran between the click handler and ApplePaySession.begin(), invalidating the iOS user-activation gesture so Safari silently aborted the session. The button still worked on desktop because desktop Safari is more permissive about gesture propagation.
• Inline Express custom fields on the product page. When the feature is enabled and there are fields to collect, the form is now rendered above the Apple Pay / Google Pay buttons instead of in a post-click modal, with debounced auto-save to session. The click handler validates locally and starts ApplePaySession.begin() synchronously, preserving the iOS user gesture.
• Express custom fields modal AJAX no longer fires when there are no fields to collect on the current page. The product page now precomputes whether any classic or Blocks-registered additional fields exist and disables the modal lookup entirely when the field set is empty, avoiding the gesture-breaking AJAX even on pages where the feature is enabled but no fields apply.
• Inline Express custom fields on the product page now try both Blocks and Classic contexts when reading additional fields, so fields registered through the Blocks API are also rendered on classic product pages.
• Inespay periodic mandate now sends the recurring amount of the subscription instead of the parent order total. The gateway reads the recurring price from WooCommerce Subscriptions, SUMO Subscriptions, YITH WooCommerce Subscriptions, Subscriptions for WooCommerce (WP Swings) and Advanced Subscriptions for WooCommerce, and falls back to the order total only when no subscription amount can be detected. The order note created on mandate creation now includes the recurring amount that was actually sent to Inespay.
• Advanced Subscriptions for WooCommerce (ASWC) support in Inespay — the gateway detects the subscription id from order meta (aswc_subscription) and reads frequency, next payment date, end date and recurring amount via aswc_get_meta_data() to build the periodic mandate.
• Inespay return handler now keeps the intermediate "Creating the mandate…" screen visible for a few seconds even when the periodic mandate link is already known on first load, so customers can read what is happening before being redirected back to Inespay to authorize the recurring mandate.
• Limited Inespay and Google Pay Redirection gateway icons to the same maximum size as Google Pay (max-width 110px, max-height 40px) in the classic checkout, preventing oversized logos when the bank-supplied image is too large.
• PHP warnings "Undefined variable $ship_address_usage / $ship_address_usage_ind" in class-wc-gateway-redsys-psd2.php when a guest customer (not logged in and no user id) checked out with a shipping address. Both variables were only initialized inside the logged-in branch but read in the outer block; they now default to first-use today, matching the existing else-branch behavior.

=
For activation, use this activator. Exclusively for Babiato.tech members.
https://babiato.tech/free-resources/woo-plugins-activator-activate-all-woo-products.42357/

Decryption key:

To view the content, you need to Sign In or Register.

WooCommerce RedSys Gateway v30.4.0

• Subscriptions section in Redsys Advanced settings to configure credentials and behavior for subscription renewal payments.
• [High]: Added missing cryptographic signature verification in successful_request() for 9 payment gateways: Apple Pay, Bizum Checkout, Bizum Redirect, Google Pay Checkout, Google Pay Redirect, Direct Debit, MasterPass, PayGold, and Bank Transfer. Without this check, payment notifications could be forged to complete orders without actual payment.
• SUMO Subscriptions renewal orders failed because sumo_save_subscription_payment_info() was called with 'payment_method' => 'insite' instead of 'redsys' in the redirect gateway callback. This caused SUMO to set the wrong payment method on renewal orders, triggering the wrong gateway filter and using incorrect credentials.
• YITH WooCommerce Subscriptions were being cancelled prematurely on failed renewals for the Redsys Redirect, InSite, Apple Pay Checkout and Google Pay Checkout gateways. The "no token / expired card" path in doing_scheduled_subscription_payment() (class-wc-gateway-redsys.php and class-wc-gateway-insite-redsys.php) called ywsbs_register_failed_payment() and then returned false, causing the YITH wrapper renew_yith_subscription() to call it again. The double increment of failed_attempts cancelled subscriptions after 1–2 real failures instead of the configured 3 retries. Apple Pay and Google Pay Checkout are also fixed since they delegate to the main Redsys handler.
• version 30.3.1
• [Medium]: Fixed an authenticated account takeover vulnerability that could allow an attacker to assume any user account, including administrators.
• [Low]: Fixed unauthenticated access to order status and user data.
• PayGold link generated from admin order metabox was never saved correctly due to an impossible response code condition in send_paygold_link(). The function now uses the same validation logic as the checkout flow (response code 9998).
• Fixed undefined $description variable in paygold_metabox_save() when sending a PayGold link from the order edit screen.
• Custom notification domain (redsys_url_notify) was broken by check_url() prepending home_url() to URLs that already had a different domain. check_url() now detects absolute URLs and preserves them as-is.
• get_notify_home_url() now automatically adds https:// when the custom notification domain is saved without a scheme.
• PHP 8.3+ compatibility — Fixed deprecated warnings for passing null/false to string functions (trim, strlen) from get_option() calls in get_txnid(), get_token_type(), and connect_standard_imap().
• PHP 8.3+ compatibility — Fixed add_submenu_page(null,...) in setup guide causing strpos()/str_replace() deprecation warnings

=
For activation, use this activator. Exclusively for Babiato.tech members.
https://babiato.tech/free-resources/woo-plugins-activator-activate-all-woo-products.42357/

WooCommerce RedSys Gateway v30.3.1
Version 30.3.1Released on 2026.03.20

• [Medium]: Fixed an authenticated account takeover vulnerability that could allow an attacker to assume any user account, including administrators.
• [Low]: Fixed unauthenticated access to order status and user data.
• PayGold link generated from admin order metabox was never saved correctly due to an impossible response code condition in send_paygold_link(). The function now uses the same validation logic as the checkout flow (response code 9998).
• Fixed undefined $description variable in paygold_metabox_save() when sending a PayGold link from the order edit screen.
• Custom notification domain (redsys_url_notify) was broken by check_url() prepending home_url() to URLs that already had a different domain. check_url() now detects absolute URLs and preserves them as-is.
• get_notify_home_url() now automatically adds https:// when the custom notification domain is saved without a scheme.
• PHP 8.3+ compatibility — Fixed deprecated warnings for passing null/false to string functions (trim, strlen) from get_option() calls in get_txnid(), get_token_type(), and connect_standard_imap().
• PHP 8.3+ compatibility — Fixed add_submenu_page(null,...) in setup guide causing strpos()/str_replace() deprecation warnings.

=
For activation, use this activator. Exclusively for Babiato.tech members.
https://babiato.tech/free-resources/woo-plugins-activator-activate-all-woo-products.42357/

Decryption key:

To view the content, you need to Sign In or Register.

WooCommerce RedSys Gateway v30.3.0
Version 30.3.0Released on 2026.03.07

• Virtual / Downloadable Products order status override in Advanced Settings. When all products in an order are virtual or downloadable, the order status can be automatically set to Completed instead of Processing.
• Redsys response code 0115 (card cancelled or account closed) now automatically deletes the stored card token, notifies the customer with instructions to add a new payment method (My account > Payment Methods), and notifies the admin.
• Admin email notification when a customer's credit card is automatically removed due to Redsys hard-decline response codes (0115, 0172, 0173).
• Improved customer email when a card is removed — now includes the last 4 digits of the card, the error code, and a direct link to add a new payment method.
• COF_INI (Credential on File initial) flag is now saved to order meta (_redsys_cof_ini) for all COF transaction types (R and C), preventing duplicate token creation when COF_INI=N.
• Conditional Rules test mode now correctly applies to the Redsys gateway URL. Previously, orders with conditional rules overriding test mode still used the default gateway URL.
• Fixed duplicate token creation when customer already has a saved card and COF_INI=N is sent to Redsys.
• Fixed undefined array key warnings in save_field_update_order_meta() when conditional rules data is incomplete.
• Fixed $redsys->debug reference using wrong variable in preauthorization logging (now uses $this->debug).
• Fixed sanitize_text_field applied before substr for HTTP_ACCEPT_LANGUAGE in Google Pay and Apple Pay Checkout, ensuring correct sanitization order.
• Google Pay Checkout now ensures WooCommerce transactional emails are initialized before calling payment_complete() in payment callbacks.

WooCommerce RedSys Gateway v30.2.1
Version 30.2.1Released on 2026.02.27

• Google Pay Express Checkout now triggers WooCommerce transactional emails after successful payment (customer and admin).

Decryption key:

To view the content, you need to Sign In or Register.

WooCommerce RedSys Gateway v30.1.0
Version 30.1.0Released on 2026.02.16

• Conditional Rules — visual rule builder to override payment parameters (terminal, merchant code, SHA256, transaction type, test mode, etc.) based on order conditions (category, tag, amount, currency, language, user role).
• Added preauthorization support for Google Pay and Apple Pay.
• Google Pay and Apple Pay now save merchant code to order meta for preauthorization operations.
• Refactored InSite payment form error handling with AJAX-based refresh instead of full page reload.
• Added post_payment_complete hooks for Bank Transfer, IMAP email processing and Inespay gateways.
• Fixed InSite COF_TYPE detection that caused incorrect credential-on-file type in REST payments.
• Fixed Ds_Card_PSD2 using wrong variable in REST payment path.
• Fixed InSite orders being marked as paid without Redsys authorization when a third-party plugin filters woocommerce_cart_needs_payment.
• Improved InSite checkout routing using REST_REQUEST instead of checkout_use_block() for reliable shortcode/block detection.
• Masked secret SHA256 key in debug logs.

Decryption key:

To view the content, you need to Sign In or Register.

WooCommerce RedSys Gateway v30.0.1
2026.02.11 - v30.0.1
* FIX: Fixed Express Payment (Google Pay / Apple Pay) not applying IRPF correctly when using Autonomos Premium. Totals now reflect the correct amount including retention.
* FIX: Improved compatibility between Express Payment custom fields and Autonomos Premium surcharge calculation.
* FIX: Fixed EMV 3DS timezone fields not being saved for users in UTC+0 timezone (e.g. Canary Islands), which could cause errors in 3D Secure authentication.