Compliance with strong customer authentication regulations

Understand authentication regulations for online credit card payments.

Overview

Regulatory agencies and card networks are introducing new requirements to strengthen security for online payments and protect consumers from fraud. Many of these regulations have included the requirement to use strong customer authentication (SCA) for online payments.

• Europe: The Revised Payment Services Directive (PSD2) requires the use of SCA for online payment transactions, except where specific exemptions or out-of-scope cases apply.
• Japan: Japan’s SCA mandate requires the use of 3D Secure (3DS) authentication for online credit card transactions with exemptions for some transaction types.

3D Secure 2 (3DS 2.0) is a technology developed by EMVCo and the card payment processing industry as a solution that ensures compliance while balancing security with a smooth checkout experience. 3DS 2.0 is the solution used within the Rapid API to provide compliance with SCA regulations.

This page explains how supported Rapid API payment types are impacted and what actions you can take to be compliant when serving your travelers.

Compliance requirements

The steps to enable compliant transactions in countries where SCA is required will vary depending on who the merchant of record is and how payments are made to the Rapid API.

When your organization is the merchant of record

Expedia Affiliate Collect

Bookings that use Expedia Affiliate Collect are unaffected by SCA regulations. No payment process or API integration changes with Rapid API are needed to reach compliance.

However, you may be impacted by the regulations if you are the merchant of record and charge the traveler’s credit card, debit card, or other form of payment that is within the scope of SCA regulations. The regulations likely require use of 3DS 2.0 as an SCA-compliant solution in the payment process. Please reach out to your payment processor to learn more about their capabilities to help merchants reach SCA compliance and avoid failed transactions.

Company cards

If your company is the merchant of record and pays Rapid API with a credit or debit card issued in a country with an SCA mandate, these card types are exempted from the SCA requirement:

• Single-use virtual cards
• Corporate cards issued to your company, not to an individual

If the listed SCA-exempt cards are not preferable, your organization can request an exemption directly from the bank that has issued your card. If an exemption is granted, transactions on that card will not require authentication except for a possible one-time online verification using 3DS 2.0. This one-time requirement can vary by bank. Please note that obtaining an exemption can be lengthy process and it will also mean that your bank may hold you liable for any fraudulent payments.

When Rapid API is the merchant of record

If your company uses Rapid API as the merchant of record by sending travelers’ cards to Rapid, you may be impacted by the regulations. When travelers book online, without a retail agent, the regulations require that payment transactions are authenticated by the traveler through SCA. The SCA-compliant process for this requirement is to use 3DS 2.0 during the payment process. If your organization wants to use Rapid API as the merchant of record with any credit or debit cards issued in countries with SCA mandates, you’ll need to adopt our solution for SCA.

Transactions that are booked through a retail agent or call center agent are exempt from the SCA requirement. Compliance for these transactions only requires an explicit indication that that booking was made with the assistance of an agent. Use the Availability API’s sales_channel field for this indication.

When the property is the merchant of record

If your company uses property collect, you may be impacted by the regulations. There are circumstances where a property may try to charge a traveler’s card without the traveler present, such as ’no show’ fees or deposits. These charges are not SCA-compliant without 3DS 2.0 authentication being performed prior to the charge. If your organization wants to use property collect for travelers using any credit or debit cards issued in countries with SCA mandates, you’ll need to adopt our solution for SCA.

The Rapid API solution

How it works

If you either use Rapid API as the merchant of record or use property collect with traveler cards, you can adopt Rapid’s API solution to generate bookings that are compliant with SCA regulations. Our APIs support SCA compliance by using 3DS 2.0 in the booking flow. With 3DS 2.0 we support risk-based authentication, which reduces friction with travelers by granting the banks discretion about when to challenge travelers to securely authenticate.

The solution for 3DS 2.0 is comprised of three distinct steps:

1. You’ll add an iframe to the check-out page that’s used to host an issuing bank’s authentication experience for the traveler. In the integration documentation this is referred to as the 3DS iframe.
2. You’ll also include a new client-side JavaScript library on the check-out page that’s used to collect browser data, communicate with the iframe, and display the SCA experience within the iframe. In the integration documentation this is referred to as the 3DS Connector Library.
3. Rapid API will accept the payer information for the bank and complete the booking after secure authentication is complete.

When using JavaScript and Rapid API together, the booking flow with SCA will now include a few additional steps before and after the Booking API is called. Below is a diagram that depicts this updated booking flow.

During each step of the revised booking flow, the output of one step contains data that is used as input into the next step. Data will need to be passed between the JavaScript on the browser and Rapid.

Note: The diagram above is a simplification of the actual API flow meant for introductory purposes. Reference the integration documentation to learn more about the complete API flow.

Integration component details

Browser iframe

The iframe, placed in the check-out experience, hosts a URL owned by the traveler’s card-issuing bank. This URL will display the authentication experience to the user and transfer any traveler-supplied information directly to their bank. The iframe should be hidden initially, with the ability to overlay it on top of the page when an authentication challenge is required after a booking attempt.

Browser JavaScript library

This library is added to the check-out page and is invoked at the time of booking to support the authentication process. The library’s APIs support the capabilities described below.

Automatic collection of traveler’s device information

Before a booking attempt, information about the traveler’s device must be collected to prepare a booking for authentication. That information is sent to the traveler’s issuing-bank for review so the bank can assess risk, decide if 3DS 2.0 authentication is required for the transaction, and ensure that it’s displayed correctly. In accordance with the 3DS 2.0 specifications, the following data will be collected from the traveler’s browser: language, color depth, screen height, screen width, time zone, user agent, and whether Java is enabled.

Display the authentication experience in the browser iframe

After a booking attempt, the library is used to display iframe overlay and load the bank’s content into the iframe. During the authentication process, the bank’s content may collect additional information about the traveler’s device to support their risk assessment. This process is needed to complete a booking.

Rapid API

Rapid API includes APIs that work in conjunction with the client-side JavaScript library. The APIs now support the capabilities described below.

Registration of traveler and payment details

Before a booking attempt, additional information about the traveler must be collected to prepare a booking for authentication. This data includes details of the traveler’s account with the point of sale and the traveler’s payment. This data is later sent to the traveler’s issuing-bank for review so the bank can assess risk and decide if secure authentication is required for the transaction. Learn more by reviewing Register Payment API in Rapid.

Completion of a payment and confirmation of booking

After a booking attempt with Rapid API and the SCA process is completed on the browser, Rapid must be invoked once more. Behind the scenes, we’ll confirm that the authentication was actually successful so that the booking can be confirmed. Learn more by reviewing the Complete Payments Session in Rapid.

Booking flow

If 3DS 2.0 is enabled in Partner Profile Rapid Support, the Price Check API will return a link to the Register Payments API instead of the Create Booking API. Below is a diagram of the API call sequence that will be required after a booking is initiated by a traveler. The sequence involves both calls to the JavaScript Library and Rapid.

When a booking is prepared for authentication, it may not always be required. The need for authentication is determined by the issuing bank of the credit card used for payment. This determination occurs during the transaction and is indicated in the in the Create Booking API response.

Below is a diagram of the API call sequence required when using Hold and Resume.

Note: The diagrams above are a simplification of the actual API flow meant for introductory purposes. Reference the integration documentation to learn more about the complete API flow.

For further information on the technical requirements for the 3DS 2.0 experience, review the EMVCo’s 3D secure protocol and core functions specification.

Rapid API and 3DS 2.0 integration guide

Supporting SCA will require integrating Rapid API with a new JavaScript library, referred to as the 3DS Connector. The two are used in conjunction to present 3DS 2.0 on the check-out page and confirm a booking. This solution supports both Expedia collect and property collect business models.

The sequence of API calls needed to support a booking with 3DS 2.0 are outlined below and detailed in the following sections:

1. JavaScript set-up method
2. Rapid Register Payment API
3. JavaScript initialize session method
4. Rapid Book API
5. JavaScript challenge method
6. Rapid Complete Payment API

To allow this sequence, 3DS 2.0 must be enabled for individual partner profiles by Rapid Partner Support.

Rapid API

If authentication is enabled for a partner profile, API responses will differ to allow a revised booking flow with 3DS 2.0.

Availability API

The value of the sales_channel field in the API request must be accurate to obtain an authentication exemption when it’s permissible by the regulations. This value, along with many other factors, is reviewed by the card’s issuing bank to make their decision during booking. Only agent tools are exempt from SCA. To specify this, set the value of sales_channel to agent_tool.

Price Check API

The API response will include a link to the Register Payments API instead of the Create Booking API.

Example response when 3DS 2.0 is enabled:

{
    "status": "matched",
    "occupancies": {
        //...(example omitted for length)
    },
    "links": {
        "payment_session": {
            "method": "POST",
            "href": "/v3/payment-sessions?token=QldfCGlcUAVgBDRwdWXBBL"
        }
    }
}

Register Payments API

This will be the second step in the SCA booking flow and occurs after the JavaScript setup method.

The request will include payment details that are part of the non-SCA booking flow and new fields that support a successful authentication. Two of these fields, encoded_browser_metadata and version, are returned from the JavaScript API’s setup method.

The response will include a payment_session_id and encoded_init_config. These are specified as inputs into the initSession method of the JavaScript library. The Booking link included in the response should be used after the initSession method.

Example request:

{
    "version": "1",
    "browser_accept_header": "*/*",
    "encoded_browser_metadata": "ZW5jb2RlZF9icm93c2VyX21ldGFkYXRh",
    "preferred_challenge_window_size": "medium",
    "merchant_url": "https://server.adomainname.net",
    "customer_account_details": {
        "authentication_method": "guest",
        "authentication_timestamp": "2018-02-12T11:59:00.000Z",
        "create_date": "2018-09-15",
        "change_date": "2018-09-17",
        "password_change_date": "2018-09-17",
        "add_card_attempts": 1,
        "account_purchases": 1
    },
    "payments": [
        {
            "type": "customer_card",
            "card_type": "VI",
            "number": "4111111111111111",
            "security_code": "123",
            "expiration_month": "08",
            "expiration_year": "2025",
            "billing_contact": {
                "given_name": "John",
                "family_name": "Smith",
                "email": "smith@example.com",
                "phone": "4875550077",
                "address": {
                    "line_1": "555 1st St",
                    "line_2": "10th Floor",
                    "line_3": "Unit 12",
                    "city": "Seattle",
                    "state_province_code": "WA",
                    "postal_code": "98121",
                    "country_code": "US"
                }
            },
            "enrollment_date": "2018-09-15"
        }
    ]
}

Example response:

{
    "payment_session_id": "76d6aaea-c1d5-11e8-a355-529269fb1459",
    "encoded_init_config": "QSBiYXNlNjQgZW5jb2RlZCBvYmplY3Qgd2hpY2ggY29udGFpbnMgY29uZmlndXJhdGlvbiBuZWVkZWQgdG8gcGVyZm9ybSBkZXZpY2UgZmluZ2VycHJpbnRpbmcgYW5kL29yIDNEUyBNZXRob2Qu",
    "links": {
        "book": {
            "method": "POST",
            "href": "/v3/itineraries?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
        }
    }
}

Create Booking API

This will be the fourth step in the SCA booking flow and occurs after the JavaScript initSession method. The request will not include any new fields for SCA---all necessary information is contained within the token of the Booking link returned by the Register Payment API. The response, if successful, will always contain an itinerary_id. However, this alone does not indicate that a booking is confirmed because 3DS 2.0 authentication may be required.

If it is required, the response will also include an encoded_challenge_config. The encoded_challenge_config and payment_session_id returned from Register Payment will need to be passed as parameters into the JavaScript challenge method.

The response will also include a new link for complete_payment_session. This link should be used after challenge method of the JavaScript library.

If 3DS 2.0 authentication is not required, the booking is confirmed and the response will include links for retrieve,cancel, and, optionally, resume.

Example Create Booking response if 3DS 2.0 authentication is required:

{
    "itinerary_id": "8999989898988",
    "links": {
        "complete_payment_session": {
            "method": "PUT",
            "href": "/v3/itineraries/8999989898988/payment-sessions?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
        }
    },
    "encoded_challenge_config": "ABElifsiejfacies2@033asfe="
}

Complete Payment Session API

This will be the sixth step in the SCA booking flow and occurs after the JavaScript challenge method. This API is required to complete the payment and inform Rapid API that a secure authentication attempt was completed, successfully or not.

The request will not include any new fields for SCA.

The response, if successful, will contain confirmation information for the booking, including an itinerary_id and links for retrieve, cancel, and, optionally, resume.

Example response:

{
    "itinerary_id": "8999989898988",
    "links": {
        "retrieve": {
            "method": "GET",
            "href": "/v3/itineraries/8999989898988?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
        }
    }
}

Iframe and JavaScript library implementation

When using the SCA booking workflow, the check-out page must include a new iframe and JavaScript library. The iframe, referred to as the 3DS iframe, will display the authentication experience using 3D-Secure 2.0. The JavaScript library, refered to as the 3DS Connector Library, will support the transfer of information to issuing banks and load the banks’ content into the iframe.

Adding the iframe

The 3DS iframe should be wrapped in a container that is initially hidden but can be displayed when an authentication challenge is required to process a payment.

The design of the container can be customized to suit the hosting page. The sample below shows an example implementation meant for guidance only, using a bootstrap modal.

<div id="threeDsIframeModal" class="modal" role="dialog">
    <div class="modal-dialog" role="document">
        <div class="modal-content">
            <div class="modal-body iframe-container">
                <div class="embed-responsive embed-responsive-16by9">
                    <iframe id="threeDsIframe" src="<<3DS iframe URL>>"> </iframe>
                </div>
            </div>
        </div>
    </div>
</div>

The source of the iframe must be set to one of two values:

The test URL supports testing and this topic is reviewed later in this document. To restrict the contents of the iframe during testing, iframe can be attributed with sandbox, but it must allow the following:

sandbox = ’allow-scripts allow-forms allow-same-origin’;

Adding the JavaScript library

The 3DS connector library communicates with the 3DS iframe and sends data to the issuing bank, which provides the iframe content. The sample below shows an example of how to add the library to the check-out page.

<head>
    <script src="<<3DS connector script URL>>" integrity="<<actual integrity value>>"></script>
</head>

The source and integrity values of the script element should be set to the below values:

Note: The source URL and integrity will change as future versions are available for adoption. Newer versions should not break existing integration. Older versions of the script will still be accessible.

Using 3DS and JavaScript for SCA

The library requires the use of JavaScript promises. The sample below shows an example implementation meant for guidance only and demonstrates how data is exchanged between the JavaScript methods and Rapid.

// Initialize the library
let connector = new PayThreeDSConnector.ThreeDSConnector("threedsiframe", "https://static.pay.expedia.com");
RapidIntegration.priceCheck(priceCheckLink)
  .then(priceCheckResponse => {
    paymentSessionLink = priceCheckResponse.links.payment_session.href;
    // Setup an authentication session with the library
    return connector.setup({ referenceId: ’1000’ })
  }).then(setupResponse => {
    console.log("Setup Response: ", setupResponse);

    // Send information from setup to Rapid’s Register Payments API
    return RapidIntegration.registerPayment(paymentSessionLink,
           setupResponse);
  }).then(paymentSessionResponse => {
    console.log("Register Payments Response: ", paymentSessionResponse);
    paymentSessionId = paymentSessionResponse.paymentSessionId;
    bookLink = paymentSessionResponse.links.book.href;
    if (paymentSessionResponse.encoded_init_config) {
      // If the payment session response contains an encoded_init_config
      // field, initialize an authentication session with the library
      // using information returned from Rapid’s Register Payments API
      connector.initSession({
        paymentSessionId: paymentSessionId,
        encodedInitConfig: paymentSessionResponse.encodedInitConfig
      }).then(initSessionResponse => {
        console.log("Init Session Response: ", initSessionResponse);
        // Then create a booking with Rapid’s Book API
        return RapidIntegration.createBooking(bookLink,
               paymentSessionId);
      })
    } else {
      // Otherwise, create a booking with Rapid’s Book API directly
      return RapidIntegration.createBooking(bookLink, paymentSessionId);
    }
  }).then(createBookingResponse => {
    console.log("Create Booking Response: ", createBookingResponse);
    itineraryId = createBookingResponse.itinerary_id;
    if (createBookingResponse.encoded_challenge_config) {
      // If the Create Booking API contains an encoded_challenge_config field,
      // display the authentication challenge window
      $(’#threeDsIframeModal).modal(’show’);
      completePaymentSessionLink = createBookingResponse.links.complete_payment_session.href;
      // Perform the challenge using the information returned from Rapid’s Register Payments API
      // and Create Booking API
      connector.challenge({
        paymentSessionId: paymentSessionId,
        encodedChallengeConfig: createBookingResponse.encodedChallengeConfig
      }).then(challengeResponse => {
        console.log("Challenge Response: ", challengeResponse);
        // Complete a booking with Rapid’s Complete Payment Session API
        return RapidIntegration.completePaymentSession(completePaymentSessionLink, itineraryId);
      }).then(completePaymentSessionResponse => {
        console.log("Complete Payment Session Response: ", completePaymentSessionResponse);
        return completePaymentSessionResponse;
      }).finally(() => {
        // Close the authentication challenge window
        $(’#threeDsIframeModal’).modal(’hide’);
      });
    } else {
      return createBookingResponse;
    }
  }).then(bookingResponse => {
    ...
  });

Note: References to the RapidIntegration class are part of the example and not part of the 3DS connector library. They are meant to demonstrate a wrapper that supports the transfer of information to the APIs.

The sample uses static values for parameters that should be determined at run time, e.g. referenceId.

Check-out page design guidelines

Card brands that support 3DS authentication may require that their logos and branding be displayed in accordance with their guidelines.

Note: Logos and guidance for other card brands will be included as they become available.

3DS connector JavaScript library documentation

Class: ThreeDSConnector

Constructor: new ThreeDSConnector(threeDsIFrameId, threeDsIFrameOrigin)

Parameters:

Setup

Set up the payment session by collecting basic details about the browser needed by backend 3DS service, such as screen size, color depth, etc.

Method signature: setup(setupRequest)

Parameters:

Returns: Promise for a SetupResponse

Intialize

Initialize the session for authentication with 3DS. As a part of the initialization, additional data may be collected from the browser. If required by the card issuer, a 3DS method URL could be loaded into the iframe to enable the card issuer’s access control server to collect data from the browser directly. The client doesn’t have to wait for the completion callback to be invoked before the order can be created.

Method signature: initSession(initSessionRequest)

Parameters:

Returns: Promise for an InitSessionResponse

Challenge

Load the 3DS authentication experience, if required by the card issuer.

Method signature: challenge(challengeRequest)

Parameters:

Returns: Promise for a ChallengeResponse

Class: SetupRequest

Request structure for the setup call.

Properties:

Class: SetupResponse

Response from the setup call.

Properties:

Class: InitSessionRequest

Request structure for the initSession method.

Properties:

Class: InitSessionResponse

Response structure for the initSession method.

Properties:

Possible values for statusCode:

Note: For all initSessionresponse statusCode values, proceed with Rapid Booking API.

Class: ChallengeRequest

Request structure for the challenge method.

Properties:

Possible values for statusCode

Note: For all challengeResponse statusCode values, proceed with Rapid API for complete payment session.

Testing with Rapid API and 3DS 2.0

Your integration with Rapid API and the 3DS connector methods can be tested with input parameter values that correspond to specific scenarios supported by the APIs.

Rapid API

To test Rapid API, include an additional HTTP header named test in the HTTP request and use one of the supported values for that API to test a supported scenario.

Within the SCA booking flow, test responses from Rapid API can also be used to test the 3DS connector library methods.

Register payments

The following test header values result in different encoded_init_config values in the API response and different HTTP response codes. The encoded_init_config can be passed in to the initSession call of the JavaScript library to trigger different test cases within the 3DS connector library.

Note: init_skip different test cases within the 3DS Connector Library.t_config that can be passed to initSession and force a statusCode of SKIPPED.

Create booking

In addition to the test headers defined in Rapid Booking Test Requests for the non-SCA booking flow, additional test header values are supported for the SCA workflow.

The test header values result in differerent encodedChallengeConfig values which can be passed in to the challenge call of the JavaScript library to trigger different test cases.

Complete payment session

The test header values result in differerent error cases that can occur when trying to complete a payment and confirm a booking.

3DS connector library and iframe

To test the 3DS connector without external dependencies, specific parameter values correspond to supported method responses. This behaviour is only supported when the iframe is loaded with the test sandbox URL.

Initialize session

The supported values of the InitSessionResponse statusCode can be tested by varying the initSessionRequest encodedInitConfig.

Note: The encoded_init_config values can also be generated with the supported test headers of the Register Payments API.

Challenge

The supported values of the challengeResponse statusCode can be tested by varying the challengeRequest encondedChallengeConfig.

The encodedInitConfig values can also be generated with the supported test headers for the SCA flow of the Booking API.

Note: When testing for challenge status code value of SUCCESS or FAILED based on user input with the iframe, the challenge method response will wait on the completion of the simulated authentication interface in the iframe.

Example of UI in 3DS iframe:

Example usage

The sample below shows an example implementation meant for guidance only. The sample demonstrates how to use the pre-defined parameter values to test the library for a 3DS challenge without the user needing to interact with the iframe.

var c = new PayThreeDSConnector.ThreeDSConnector(’threedsiframe’, ’https://static.pay.expedia.com’); // change to match the 3DS iframe ID
c.setup({ referenceId: ’1000’ })
    .then((setupResponse) => {
        console.log(’Setup Output: ’, setupResponse);
        return c.initSession({
            paymentSessionId: 1,
            encodedInitConfig: ’ W3sicHJvdmlkZXJJZCI6IDAsICJzYW5kYm94SW5pdE91dHB1dENvbmZpZyI6ICJTVUNDRVNTIn1d’,
        }); // SUCCESS
    })
    .then((initResponse) => {
        console.log(’InitSession Output: ’, initResponse);
        $(’#threedsIframeModal’).modal(); // replace with code to show the modal containing the 3DS iframe
        return c.challenge({
            paymentSessionId: 1,
            encodedChallengeConfig:
                ’ W3sicHJvdmlkZXJJZCI6IDAsICJzYW5kYm94Q2hhbGxlbmdlT3V0cHV0Q29uZmlnIjogIlNVQ0NFU1MifV0=’,
        }); // SUCCESS
    })
    .then((challengeResponse) => {
        console.log(’Challenge Output: ’, challengeResponse);
    })
    .finally(() => {
        $(’#threedsIframeModal’).modal(’hide’); // replace with code to hide the modal containing the 3DS iframe
    });

3DS authentication and property collect

When booking with property collect, Expedia does not charge the card. Instead, we send it to the property for handling. The property may use this information to validate the card ahead of check-in. The traveler is expected to pay in person at check-in.

However, sometimes travelers cannot check in and properties may charge a no-show fee. These charges can be impacted by SCA regulations because they involve charging a card when the traveler is not present.

If transactions are impacted, payments can fail or properties can face penalties from card brands if the charge is non-compliant.

To protect our relationship with properties and continue to serve our partners, Expedia Group is offering properties an optional path to compliance. Impacted properties can now leverage Expedia Group to provide authentication on their behalf. This allows properties to protect their business and ensures that Rapid API can continue to offer the same diverse range of properties.

Rapid API provides the flag of <payment_registration_recommended=true> in the Property Content File and in Property Content, which can help you to identify a property when it is potentially involved in the project.

Possible impacts to an integration

If you want to offer properties that can require secure authentication, then the booking path should support 3DS. Without supporting 3DS, booking these properties may fail if the card-issuing bank determines authentication is necessary for the transaction.

When a no-show fee is charged by the property, Rapid API will be the merchant of record. The charge’s descriptor on the card’s billing statement will be defined by your organization, not the property. To customize this text, contact Rapid Partner Support.

To remain compliant with the requirements of card brands and the Rapid API launch process, use the Accepted Payments API to display the processing_country on the check-out page in case of no-show. This is required for all transactions where Rapid API is the merchant of record, and it may occur if 3DS is used and a no-show occurs.

How to mitigate the impact on integration

If a Rapid API integration does not support secure authentication in the booking flow, the risk of failed bookings can be reduced by not selling these properties. Contact Rapid Partner Support to have the affected property collect rates removed from your Availability API responses.

When using an agent tool, the transaction is exempted from SCA in accordance with the regulations. Use the Availability API’s sales_channel field to indicate this.

Error handling

The Create Booking API and Complete Payment Session API may result in confirmed bookings and payment transactions.

Your integration should consider the following instructions to avoid financial loss and customer operation cases: