Merge pull request #9 from cybersource-tpi/main

v24.1.1

Author: ohernandovisa

Jenkinsfile

@@ -109,7 +109,7 @@ podTemplate(
                 reportName           : 'Code Coverage Reports'
             ])
 
-            step([$class: 'Mailer', notifyEveryUnstableBuild: true, recipients: '[email protected]'])
+            step([$class: 'Mailer', notifyEveryUnstableBuild: true, recipients: ''])
             notifySlack(this, "cybersource-jenkins", false)
         }
     }

Jenkinsfile.publish

@@ -145,7 +145,7 @@ podTemplate(
         currentBuild.result = 'FAILURE'
         throw any
     } finally {
-        step([$class: 'Mailer', notifyEveryUnstableBuild: true, recipients: '[email protected]'])
+        step([$class: 'Mailer', notifyEveryUnstableBuild: true, recipients: ''])
         notifySlack(this, "cybersource-jenkins", false)
     }
 }}

README.md

@@ -1,4 +1,4 @@
-# ISV OCC Payment
+# Cybersource Official
 
 ## Documentation
 

documentation/Oracle Commerce Cloud Installation Guide.pdf

@@ -24,9 +24,12 @@ In case you would like [disable DM checks](https://developer.cybersource.com/api
 
 In case DM is enabled for a particular payment method and transaction is marked for Review authorization is still considered successfully from OCC standpoint. Webhook response code will still be '1000' and additional response reason (`AUTHORIZED_PENDING_REVIEW`) will be returned back to OCC so that interested parties (e.g. OMS) can detect such transaction in OCC being marked for review.
 
+In case DM is enabled for a particular payment method and transaction is rejected after authorization with response reason(`AUTHORIZED_RISK_DECLINED`).Authorization Reversal will be triggered automatically. 
+
+
 From the referenced document we can follow the recommended approach for `Review` decisions:
 
-1. A shopper enters credit card information and submits the order
+1. A shopper enters card information and submits the order
 2. OCC processes the order and triggers the payment webhook with transaction type “Authorize” to request authorization for the order
 3. The Payment Integration Service receives this request and can function as the integration point for fraud detection
 4. The Payment Integration Service invokes the fraud detection service along with authorization

documentation/Oracle Commerce Cloud- Cybersource User Installation Guide.pdf documentation/Oracle Commerce Cloud- Cybersource Official User Installation Guide.pdf

@@ -86,7 +86,7 @@ Once the module is installed, head back to the Oracle Commerce Cloud Admin to co
 After successful deployment you will need to enable payment gateway:
 
 - Go to OCC Admin -> Settings -> Payment Processing
-- Open 'Payment gateways' tab and choose 'ISV OCC Gateway' from the list
+- Open 'Payment gateways' tab and choose 'Cybersource Official' from the list
 - Select 'Payment Gateway Enabled' option
 - Configure gateway settings by providing values (e.g. merchant credentials) for particular channel (Preview, Storefront, Agent)
 - Save Changes

documentation/business-services/decision-manager.md

@@ -16,8 +16,8 @@ The custom payment plugin solution provides an integration layer between OCC and
         - Refund
     - Tokenized card payment based on Microform v2
     - Payer authentication support (3D Secure)
-    - Network tokenization
-    - Store tokenized credit card against user profile
+    - Network Tokens
+    - Store tokenized credit/debit card against user profile
         - Payments using stored credit cards
 2. Online Authorizations
     - Supported services

documentation/images/extension-version.png

@@ -1,5 +1,5 @@
 
-# ISV OCC Payment Plugin
+# Cybersource Official Payment Plugin
 
 ## Oracle Commerce Cloud
 
@@ -11,7 +11,7 @@
 | [Package Contents](package-contents.md)                        | Detailed explanation of each package included into solution. Documents available payment gateway settings                    |
 | [Installation](installation.md)                                | Go through installation steps to deploy and configure payment extensions to OCC                                              |
 | _Payment Services_                                             |                                                                                                                              |
-| [Credit Card](payment-services/credit-card.md)                 | Detailed information about credit card payment services, e.g.Microform integration, Payer Authentication (3DSecure) etc |
+| [Credit Card](payment-services/credit-card.md)                 | Detailed information about card payment services, e.g.Microform integration, Payer Authentication (3DSecure) etc |
 | [GooglePay](payment-services/googlepay.md)                     | Documents GooglePay integration and related technical details                                                                |
 | [ApplePay](payment-services/applepay.md)                       | Documents ApplePay integration and related technical details. Includes ApplePay setup steps                                  |
 | [Settlement and Refund](payment-services/settlement-refund.md) | Additional payment services to allow fulfillment processes to settle or refund particular transactions when needed           |
@@ -23,7 +23,7 @@
 
 ## Audience and Purpose
 
-This document is written for merchants who want to use Payment and Value added Business services. This document provides an overview for integrating ISV OCC payment services into Oracle Commerce Cloud platform.
+This document is written for merchants who want to use Payment and Value added Business services. This document provides an overview for integrating Cybersource Official payment services into Oracle Commerce Cloud platform.
 
 ## Conventions
 

documentation/images/merchantId.png

@@ -56,7 +56,7 @@ The `payment-gateway` package hold gateway settings definition according to [Sup
 .
 ├── ext.json
 ├── gateway
-│   └── isv-occ-gateway // name of the  gateway
+│   └── isv-occ-gateway 
 │       ├── config
 │       │   ├── config.json // configuration properties
 │       │   └── locales
@@ -69,7 +69,7 @@ The `gateway/isv-occ-gateway/gateway.json` file has the following definition:
 
 ```json
 {
-  "provider": "ISV OCC Gateway",
+  "provider": "Cybersource Official",
   "paymentMethodTypes": ["generic", "card"],
   "transactionTypes": {
     "generic": ["initiate", "retrieve", "authorization", "void", "refund"],
@@ -178,8 +178,6 @@ server-extension
  ┃ ┗ Resources_en.properties
  ┣ src
  ┃ ┣ common
- ┃ ┃ ┣ logging
- ┃ ┃ ┃ ┗ occLogger.ts
  ┃ ┃ ┣ genericDispatcher.ts
  ┃ ┃ ┗ index.ts
  ┃ ┣ controllers
@@ -199,6 +197,7 @@ server-extension
  ┃ ┃ ┣ paymentMethods.ts
  ┃ ┃ ┣ paymentRefund.ts
  ┃ ┃ ┣ paymentRouter.js
+ ┃ ┃ ┣ payments.ts
  ┃ ┃ ┣ report.ts
  ┃ ┃ ┗ webhookRouter.ts
  ┃ ┣ errors
@@ -231,9 +230,11 @@ server-extension
  ┃ ┃ ┃ ┃ ┣ generateKey.ts
  ┃ ┃ ┃ ┃ ┣ paymentCommand.ts
  ┃ ┃ ┃ ┃ ┣ processAuthorizationReversal.ts
+ ┃ ┃ ┃ ┃ ┣ processAutoAuthorizationReversal.ts
  ┃ ┃ ┃ ┃ ┣ processCapture.ts
  ┃ ┃ ┃ ┃ ┣ processPayment.ts
- ┃ ┃ ┃ ┃ ┗ processRefund.ts
+ ┃ ┃ ┃ ┃ ┣ processRefund.ts
+ ┃ ┃ ┃ ┃ ┗ processWebhookSubscription.ts
  ┃ ┃ ┃ ┣ converters
  ┃ ┃ ┃ ┃ ┣ request
  ┃ ┃ ┃ ┃ ┃ ┣ mappers
@@ -313,6 +314,7 @@ server-extension
  ┃ ┃ ┃ ┃ ┣ deviceFingerprintSessionIdValidator.ts
  ┃ ┃ ┃ ┃ ┗ transientTokenValidator.ts
  ┃ ┃ ┃ ┣ applePayService.ts
+ ┃ ┃ ┃ ┣ autoAuthReversalService.ts
  ┃ ┃ ┃ ┣ deviceFingerprintService.ts
  ┃ ┃ ┃ ┣ flexService.ts
  ┃ ┃ ┃ ┣ payerAuthSetupService.ts

documentation/installation.md

@@ -49,12 +49,12 @@ Default values:
 
 You will need to go through the steps from the [Configure Apple Pay on the web](https://help.apple.com/developer-account/#/dev1731126fb) in order to setup ApplePay payments
 
-1. Go to  EBC portal -> Payment Configuration -> Digital Payment Solutions
+1. Go to Business Centre -> Payment Configuration -> Digital Payment Solutions
 2. Configure ApplePay by generating  certificate signing request (CSR) and providing Apple Merchant ID
 3. `applePayMerchantId` gateway setting should get the value of the introduced Apple Merchant ID
 4. Download CSR
 5. Create merchant identify in your ApplePay dev account (as per docs)
-6. Create Apple Pay Payment Processing Certificate for the identity you have just created (upload the certificate file downloaded from EBC in previous step)
+6. Create Apple Pay Payment Processing Certificate for the identity you have just created (upload the certificate file downloaded from  Business Centre in previous step)
 7. Create merchant identity certificate. This certificate is used on the Web when a session validation request is triggered.
 8. Register merchant domain and verify it (https://help.apple.com/developer-account/#/dev1731126fb). Merchant domain is where an application is being deployed to.
 

documentation/introduction.md

@@ -9,8 +9,9 @@
    3. [Payer Authentication](#payer-authentication)
       1. [UI integration details](#ui-integration-details-1)
       2. [Backend (SSE) integration details](#backend-sse-integration-details-1)
-      3. [Strong Customer Authentication (SCA)](#strong-customer-authentication-sca)
-   4. [Network Tokenization](#network-tokenization)
+      3. [Decision Manager with Payer Authentication](#decision-manager-with-payer-authentication)
+      4. [Strong Customer Authentication (SCA)](#strong-customer-authentication-sca)
+   4. [Network Tokens](#network-tokenization)
    5. [Capturing funds during authorization (SALE)](#capturing-funds-during-authorization-sale)
 
 ## Description
@@ -29,7 +30,7 @@ The following applies to credit card payments:
 
 - Credit card payments using [Microform v2](https://developer.cybersource.com/api/developer-guides/dita-flex/SAFlexibleToken/FlexMicroform.html). The transient token represents both card number (PAN) and CVV. Only token, card expiration date and masked card number going to be sent in a webhook request.
 - Payer Authentication (3D Secure)
-- Shopper can choose to save credit card as part of profile
+- Shopper can choose to save credit/debit card as part of profile
 - Subscribe to Network Token life cycle updates
 - Shopper can pay with a saved card
 
@@ -63,13 +64,13 @@ Default values:
 
 ### Microform Card Payments
 
-The following describes the end to end use case with an option to save credit card:
+The following describes the end to end use case with an option to save credit/debit card:
 
 1. Shopper chooses to checkout
-2. Shopper enters credit card information
-3. Credit card information is sent to payment provider client side and a one time (transient) use token is returned.
+2. Shopper enters card information
+3. Credit/Debit card information is sent to payment provider client side and a one time (transient) use token is returned.
 4. Save the one time client token and include the client token in the payment part of the order
-5. Shopper chooses to save the credit card for later
+5. Shopper chooses to save the card for later
 6. Shopper places the order
 7. Payment webhook is triggered with transaction type "0100" (authorize). The following properties sent in the request:
     - Transient token
@@ -92,7 +93,7 @@ Below are credit card related components from Payment Widget:
 
 The application is structured based on OSF especifications.
 
-Inside the components there is the list of widgets that are necessary to integrate the credit card payment using Cybersource.
+Inside the components there is the list of widgets that are necessary to integrate the card payment using Cybersource.
 Inside the endpoints folder there is specific call to REST apis
 Fetchers are used to call APIs before the widget is redered. This are used to load data that widgets need before they can be rendered in the page. Fetchers can be global or local that means that some fetcher will be contained inside the components/widget folder (where widget is your custom widget).
 Actions are used to call APIs but when the user performeces an action like clicking a button.
@@ -105,7 +106,7 @@ REST API for Oracle Commerce Cloud 22D [Oracle Commerce Cloud](https://docs.orac
 
 Microform Integration v2 Documentation [Microform v2](https://developer.cybersource.com/docs/cybs/en-us/digital-accept-flex/developer/all/rest/digital-accept-flex/microform-integ-v2.html)
 
-The structure that follows contain all the components necessary to run Credit Card Payment in OSF.
+The structure that follows contain all the components necessary to run Card Payment in OSF.
 
 ```text
 plugins
@@ -190,8 +191,8 @@ plugins
 
 
 - Before Payment Widget is rendered available payment methods are retrieved from SSE `/ccstorex/custom/isv-payment/v2/paymentMethods` endpoint. Saved credit cards are also retrieved from OCC in case user is logged-in.
-- `Card` component renders by default list of saved cards if it is not empty and user is logged-in. Otherwise credit card form is rendered
-- Credit card form is managed by `IsvCheckoutCardDetails` component. Saved cards are managed by `IsvCheckoutSavedCards` component. Shopper can switch between both components to choose preferable way to pay.
+- `Card` component renders by default list of saved cards if it is not empty and user is logged-in. Otherwise credit/debit card form is rendered
+- Card Payment form is managed by `IsvCheckoutCardDetails` component. Saved cards are managed by `IsvCheckoutSavedCards` component. Shopper can switch between both components to choose preferable way to pay.
 - Microform is initialized by fetching keys from SSE using `/ccstorex/custom/isv-payment/v2/keys` endpoint
 - Transient token is generated client side and is then included into payment details during order submission
 - In case shopper pays with saved card only savedCardId is sent and transient token is not generated. Shopper can also choose to set card as default
@@ -203,7 +204,7 @@ List of related controllers:
 - `server-extension/src/controllers/paymentMethods.ts` - return supported payment method configurations
 - `server-extension/src/controllers/flex.ts` - generate Microform keys
 
-The list of handlers processing credit card Webhook requests in SSE can be found in `server-extension/src/services/payments/index.ts`
+The list of handlers processing credit/debit card Webhook requests in SSE can be found in `server-extension/src/services/payments/index.ts`
 
 | **Operation**    | **Handlers**                    | **Description**                                                                                                  |
 |------------------|---------------------------------|------------------------------------------------------------------------------------------------------------------|
@@ -243,10 +244,10 @@ Payer authentication is enabled by default using `payerAuthEnabled` gateway sett
 Generally payer authentication services are executed together with credit card authorization:
 
 1. PayerAuth setup is created using card information using `/ccstorex/custom/isv-payment/v2/payerAuth/setup` SSE endpoint
-2. Credit card is tokenized as per process described in the [Microform Card Payments](#microform-card-payments) section
+2. Credit/Debit card is tokenized as per process described in the [Microform Card Payments](#microform-card-payments) section
 3. Order is created and "Authorize" Webhook request is triggered
 4. Credit card Authorization service is called along with Payer Auth Enrollment
-5. In case credit card is enrolled in payer authentication, authorization is rejected with specific reason code (10000). The response from payment provider will contain all data needed to start consumer authentication flow in storefront
+5. In case card is enrolled in payer authentication, authorization is rejected with specific reason code (10000). The response from payment provider will contain all data needed to start consumer authentication flow in storefront
 6. Payer Auth data is included in Webhook response using custom payment properties
 7. In storefront Cardinal Cruise continues the consumer authentication flow with the custom payment properties returned in Webhook response.
 8. Popup window is displayed to finish consumer authentication
@@ -273,6 +274,10 @@ The following UI component contains Payer Authentication integration logic `plug
 - `server-extension/src/services/payments/converters/request/mappers/payerAuthEnrollMapper.ts` Including payer auth reference id into PSP card authorization request
 - `server-extension/src/services/payments/converters/request/mappers/payerAuthValidationMapper.ts` Including payer auth validation token into PSP card authorization request
 
+#### Decision Manager with Payer Authentication
+You can use Decision Manager with payer authentication services to allow the risk of an order to determine when you need to invoke payer authentication.
+[Decision Manager with Payer Authentication](https://ebc.cybersource.com/content/ebc/docs/cybs/en-us/html/dm-develop/developer/all/so/oxy_ex-1/topics/c_Using_DM_With_Payer_Auth.html)
+
 #### Strong Customer Authentication (SCA)
 
 When `Payer Authentication` is enabled, if a transaction gets declined with the reason as Strong Customer Authentication required, then another request will be sent from Oracle Commerce Cloud automatically for the same order and the customer will be 3DS challenged. 
@@ -283,13 +288,13 @@ In case 'Strong Customer Authentication' is enabled for credit cards, '10000' re
 
 *Note:* The `scaEnabled` setting is applicable only if `Payer Authentication` is enabled.
 
-### Network Tokenization
+### Network Tokens
 
-A Network Token is a network scheme generated token, that represents customer card information for secure transactions that references a customer’s actual PAN.  
+A Network Token is a card scheme generated token, that represents customer card information for secure transactions that references a customer’s actual PAN.  
 
-Before a MID can be enabled for Network Tokenization, it must be provisioned with a Token Requestor ID (TRID) for each card scheme. 
+Before a MID can be enabled for Network Token, it must be provisioned with a Token Requestor ID (TRID) for each card scheme. Please contact your Cybersource representative or reseller to arrange for Network Tokens to be enabled on your Cybersource account.
 
-Plug-in would need to subscribe to the necessary webhook notifications and ingest them for changes to the card. Subscription is created automatically when Authorization is processed, while the Webhook Subscription feature is enabled.  
+Plug-in would need to subscribe to the necessary webhook notifications and ingest them for changes to the card. Webhook subscription to the Network Token life cycle updates is created when authorization is processed, while the Network Token Updates is enabled in the back office.  
 
 The following describes the Network Token update process:
 
@@ -300,7 +305,7 @@ The following describes the Network Token update process:
 5. The expiry month, expiry year, and card suffix will be updated with the latest details.
 6. The updated card details will be saved in OCC.
 
-![Network Tokenization](images/network-token.png)
+![Network Token](images/network-token.png)
 
 ### Capturing funds during authorization (SALE)