cybersource-rest-client 0.0.38 → 0.0.39
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.idea/inspectionProfiles/Project_Default.xml +6 -0
- package/.idea/misc.xml +8 -0
- package/.idea/vcs.xml +6 -0
- package/.idea/workspace.xml +47 -4
- package/cybersource-rest-client-0.0.38.tgz +0 -0
- package/docs/PtsV2PaymentsPost201Response.md +1 -0
- package/docs/PtsV2PaymentsPost201ResponseConsumerAuthenticationInformation.md +1 -1
- package/docs/PtsV2PaymentsPost201ResponseIssuerInformation.md +1 -0
- package/docs/PtsV2PaymentsPost201ResponsePaymentInsightsInformation.md +8 -0
- package/docs/PtsV2PaymentsPost201ResponsePaymentInsightsInformationResponseInsights.md +9 -0
- package/docs/Ptsv2paymentsConsumerAuthenticationInformation.md +2 -2
- package/docs/Ptsv2paymentsPaymentInformationCard.md +1 -0
- package/docs/Ptsv2paymentsPaymentInformationTokenizedCard.md +3 -2
- package/docs/Ptsv2paymentsPointOfSaleInformationEmv.md +1 -1
- package/docs/Ptsv2paymentsProcessingInformation.md +1 -0
- package/docs/Ptsv2paymentsProcessingInformationAuthorizationOptionsInitiator.md +1 -1
- package/docs/Ptsv2paymentsidProcessingInformationAuthorizationOptionsInitiator.md +1 -1
- package/docs/ReportingV3ChargebackDetailsGet200ResponseChargebackDetails.md +1 -0
- package/docs/RiskV1AuthenticationResultsPost201ResponseConsumerAuthenticationInformation.md +3 -0
- package/docs/RiskV1DecisionsPost201ResponseConsumerAuthenticationInformation.md +4 -1
- package/docs/Riskv1authenticationresultsConsumerAuthenticationInformation.md +4 -2
- package/docs/{TssV2TransactionsPost201ResponseEmbeddedDeviceInformation.md → Riskv1authenticationresultsDeviceInformation.md} +1 -1
- package/docs/Riskv1authenticationresultsPaymentInformationTokenizedCard.md +1 -1
- package/docs/Riskv1authenticationsPaymentInformationTokenizedCard.md +3 -1
- package/docs/Riskv1authenticationsetupsPaymentInformationTokenizedCard.md +1 -1
- package/docs/Riskv1decisionsConsumerAuthenticationInformation.md +3 -2
- package/docs/Riskv1decisionsPaymentInformationTokenizedCard.md +1 -1
- package/docs/SecureFileShareApi.md +2 -2
- package/docs/TssV2TransactionsGet200Response.md +1 -0
- package/docs/TssV2TransactionsGet200ResponsePaymentInformationCustomer.md +1 -1
- package/docs/TssV2TransactionsGet200ResponseProcessingInformationAuthorizationOptions.md +1 -1
- package/docs/TssV2TransactionsGet200ResponseProcessingInformationAuthorizationOptionsInitiator.md +11 -0
- package/docs/TssV2TransactionsPost201ResponseEmbeddedPaymentInformation.md +2 -1
- package/docs/TssV2TransactionsPost201ResponseEmbeddedPaymentInformationBank.md +8 -0
- package/docs/TssV2TransactionsPost201ResponseEmbeddedPaymentInformationBankAccount.md +9 -0
- package/docs/TssV2TransactionsPost201ResponseEmbeddedPaymentInformationCustomer.md +8 -0
- package/docs/TssV2TransactionsPost201ResponseEmbeddedTransactionSummaries.md +1 -1
- package/docs/ValidateRequest.md +1 -0
- package/package.json +1 -1
- package/src/api/SecureFileShareApi.js +2 -2
- package/src/index.js +38 -8
- package/src/model/PtsV2PaymentsPost201Response.js +12 -4
- package/src/model/PtsV2PaymentsPost201ResponseConsumerAuthenticationInformation.js +1 -1
- package/src/model/PtsV2PaymentsPost201ResponseIssuerInformation.js +9 -0
- package/src/model/PtsV2PaymentsPost201ResponsePaymentInsightsInformation.js +81 -0
- package/src/model/PtsV2PaymentsPost201ResponsePaymentInsightsInformationResponseInsights.js +91 -0
- package/src/model/Ptsv2paymentsConsumerAuthenticationInformation.js +2 -2
- package/src/model/Ptsv2paymentsPaymentInformationCard.js +9 -0
- package/src/model/Ptsv2paymentsPaymentInformationTokenizedCard.js +11 -2
- package/src/model/Ptsv2paymentsPointOfSaleInformationEmv.js +3 -3
- package/src/model/Ptsv2paymentsProcessingInformation.js +9 -0
- package/src/model/Ptsv2paymentsProcessingInformationAuthorizationOptionsInitiator.js +3 -3
- package/src/model/Ptsv2paymentsidProcessingInformationAuthorizationOptionsInitiator.js +3 -3
- package/src/model/ReportingV3ChargebackDetailsGet200ResponseChargebackDetails.js +9 -0
- package/src/model/RiskV1AuthenticationResultsPost201ResponseConsumerAuthenticationInformation.js +27 -0
- package/src/model/RiskV1DecisionsPost201ResponseConsumerAuthenticationInformation.js +28 -1
- package/src/model/Riskv1authenticationresultsConsumerAuthenticationInformation.js +20 -2
- package/src/model/{TssV2TransactionsPost201ResponseEmbeddedDeviceInformation.js → Riskv1authenticationresultsDeviceInformation.js} +8 -8
- package/src/model/Riskv1authenticationresultsPaymentInformationTokenizedCard.js +1 -1
- package/src/model/Riskv1authenticationsPaymentInformationTokenizedCard.js +24 -3
- package/src/model/Riskv1authenticationsetupsPaymentInformationTokenizedCard.js +2 -2
- package/src/model/Riskv1decisionsConsumerAuthenticationInformation.js +11 -2
- package/src/model/Riskv1decisionsPaymentInformationTokenizedCard.js +1 -1
- package/src/model/TssV2TransactionsGet200Response.js +12 -4
- package/src/model/TssV2TransactionsGet200ResponsePaymentInformationCustomer.js +1 -1
- package/src/model/TssV2TransactionsGet200ResponseProcessingInformationAuthorizationOptions.js +6 -6
- package/src/model/TssV2TransactionsGet200ResponseProcessingInformationAuthorizationOptionsInitiator.js +108 -0
- package/src/model/TssV2TransactionsPost201ResponseEmbeddedPaymentInformation.js +14 -6
- package/src/model/TssV2TransactionsPost201ResponseEmbeddedPaymentInformationBank.js +81 -0
- package/src/model/TssV2TransactionsPost201ResponseEmbeddedPaymentInformationBankAccount.js +91 -0
- package/src/model/TssV2TransactionsPost201ResponseEmbeddedPaymentInformationCustomer.js +82 -0
- package/src/model/TssV2TransactionsPost201ResponseEmbeddedTransactionSummaries.js +6 -6
- package/src/model/ValidateRequest.js +12 -4
package/.idea/misc.xml
ADDED
package/.idea/vcs.xml
ADDED
package/.idea/workspace.xml
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
2
2
|
<project version="4">
|
|
3
3
|
<component name="ChangeListManager">
|
|
4
|
-
<list default="true" id="69db6054-f163-40a2-925e-c9ec35e3cc46" name="Changes" comment="">
|
|
5
|
-
<change beforePath="$PROJECT_DIR$/
|
|
4
|
+
<list default="true" id="69db6054-f163-40a2-925e-c9ec35e3cc46" name="Changes" comment="June release changes">
|
|
5
|
+
<change beforePath="$PROJECT_DIR$/generator/cybersource_node_sdk_gen.bat" beforeDir="false" afterPath="$PROJECT_DIR$/generator/cybersource_node_sdk_gen.bat" afterDir="false" />
|
|
6
6
|
</list>
|
|
7
7
|
<option name="SHOW_DIALOG" value="false" />
|
|
8
8
|
<option name="HIGHLIGHT_CONFLICTS" value="true" />
|
|
@@ -23,6 +23,8 @@
|
|
|
23
23
|
<component name="HighlightingSettingsPerFile">
|
|
24
24
|
<setting file="file://$PROJECT_DIR$/generator/cybersource-javascript-template/api.mustache" root0="FORCE_HIGHLIGHTING" />
|
|
25
25
|
<setting file="file://$PROJECT_DIR$/generator/cybersource-rest-spec.json" root0="FORCE_HIGHLIGHTING" />
|
|
26
|
+
<setting file="file://$PROJECT_DIR$/generator/cybersource_node_sdk_gen.sh" root0="FORCE_HIGHLIGHTING" />
|
|
27
|
+
<setting file="file://$PROJECT_DIR$/package.json" root0="FORCE_HIGHLIGHTING" />
|
|
26
28
|
<setting file="file://$PROJECT_DIR$/src/authentication/logging/Logger.js" root0="FORCE_HIGHLIGHTING" />
|
|
27
29
|
<setting file="file://$PROJECT_DIR$/src/authentication/logging/SensitiveDataMasker.js" root0="FORCE_HIGHLIGHTING" />
|
|
28
30
|
<setting file="file://$PROJECT_DIR$/src/authentication/logging/SensitiveDataTags.js" root0="FORCE_HIGHLIGHTING" />
|
|
@@ -60,8 +62,33 @@
|
|
|
60
62
|
<updated>1652245926043</updated>
|
|
61
63
|
<workItem from="1652245929317" duration="11829000" />
|
|
62
64
|
<workItem from="1652678985213" duration="5024000" />
|
|
63
|
-
<workItem from="1653109252715" duration="
|
|
65
|
+
<workItem from="1653109252715" duration="2058000" />
|
|
66
|
+
<workItem from="1654678247507" duration="2446000" />
|
|
67
|
+
<workItem from="1654842830853" duration="637000" />
|
|
68
|
+
<workItem from="1655096994637" duration="7823000" />
|
|
64
69
|
</task>
|
|
70
|
+
<task id="LOCAL-00001" summary="May release : Updated the version">
|
|
71
|
+
<created>1653110218613</created>
|
|
72
|
+
<option name="number" value="00001" />
|
|
73
|
+
<option name="presentableId" value="LOCAL-00001" />
|
|
74
|
+
<option name="project" value="LOCAL" />
|
|
75
|
+
<updated>1653110218613</updated>
|
|
76
|
+
</task>
|
|
77
|
+
<task id="LOCAL-00002" summary="June 2022 spec file">
|
|
78
|
+
<created>1655201751432</created>
|
|
79
|
+
<option name="number" value="00002" />
|
|
80
|
+
<option name="presentableId" value="LOCAL-00002" />
|
|
81
|
+
<option name="project" value="LOCAL" />
|
|
82
|
+
<updated>1655201751432</updated>
|
|
83
|
+
</task>
|
|
84
|
+
<task id="LOCAL-00003" summary="June release changes">
|
|
85
|
+
<created>1655202568347</created>
|
|
86
|
+
<option name="number" value="00003" />
|
|
87
|
+
<option name="presentableId" value="LOCAL-00003" />
|
|
88
|
+
<option name="project" value="LOCAL" />
|
|
89
|
+
<updated>1655202568348</updated>
|
|
90
|
+
</task>
|
|
91
|
+
<option name="localTasksCounter" value="4" />
|
|
65
92
|
<servers />
|
|
66
93
|
</component>
|
|
67
94
|
<component name="TypeScriptGeneratedFilesManager">
|
|
@@ -89,7 +116,7 @@
|
|
|
89
116
|
<entry key="branch">
|
|
90
117
|
<value>
|
|
91
118
|
<list>
|
|
92
|
-
<option value="
|
|
119
|
+
<option value="june-2022-release" />
|
|
93
120
|
</list>
|
|
94
121
|
</value>
|
|
95
122
|
</entry>
|
|
@@ -105,6 +132,16 @@
|
|
|
105
132
|
<entry key="Branch">
|
|
106
133
|
<value>
|
|
107
134
|
<list>
|
|
135
|
+
<RecentGroup>
|
|
136
|
+
<option name="FILTER_VALUES">
|
|
137
|
+
<option value="june-2022-release" />
|
|
138
|
+
</option>
|
|
139
|
+
</RecentGroup>
|
|
140
|
+
<RecentGroup>
|
|
141
|
+
<option name="FILTER_VALUES">
|
|
142
|
+
<option value="master" />
|
|
143
|
+
</option>
|
|
144
|
+
</RecentGroup>
|
|
108
145
|
<RecentGroup>
|
|
109
146
|
<option name="FILTER_VALUES">
|
|
110
147
|
<option value="may-release-2022" />
|
|
@@ -116,4 +153,10 @@
|
|
|
116
153
|
</map>
|
|
117
154
|
</option>
|
|
118
155
|
</component>
|
|
156
|
+
<component name="VcsManagerConfiguration">
|
|
157
|
+
<MESSAGE value="May release : Updated the version" />
|
|
158
|
+
<MESSAGE value="June 2022 spec file" />
|
|
159
|
+
<MESSAGE value="June release changes" />
|
|
160
|
+
<option name="LAST_COMMIT_MESSAGE" value="June release changes" />
|
|
161
|
+
</component>
|
|
119
162
|
</project>
|
|
Binary file
|
|
@@ -15,6 +15,7 @@ Name | Type | Description | Notes
|
|
|
15
15
|
**issuerInformation** | [**PtsV2PaymentsPost201ResponseIssuerInformation**](PtsV2PaymentsPost201ResponseIssuerInformation.md) | | [optional]
|
|
16
16
|
**paymentAccountInformation** | [**PtsV2PaymentsPost201ResponsePaymentAccountInformation**](PtsV2PaymentsPost201ResponsePaymentAccountInformation.md) | | [optional]
|
|
17
17
|
**paymentInformation** | [**PtsV2PaymentsPost201ResponsePaymentInformation**](PtsV2PaymentsPost201ResponsePaymentInformation.md) | | [optional]
|
|
18
|
+
**paymentInsightsInformation** | [**PtsV2PaymentsPost201ResponsePaymentInsightsInformation**](PtsV2PaymentsPost201ResponsePaymentInsightsInformation.md) | | [optional]
|
|
18
19
|
**orderInformation** | [**PtsV2PaymentsPost201ResponseOrderInformation**](PtsV2PaymentsPost201ResponseOrderInformation.md) | | [optional]
|
|
19
20
|
**pointOfSaleInformation** | [**PtsV2PaymentsPost201ResponsePointOfSaleInformation**](PtsV2PaymentsPost201ResponsePointOfSaleInformation.md) | | [optional]
|
|
20
21
|
**installmentInformation** | [**PtsV2PaymentsPost201ResponseInstallmentInformation**](PtsV2PaymentsPost201ResponseInstallmentInformation.md) | | [optional]
|
|
@@ -9,7 +9,7 @@ Name | Type | Description | Notes
|
|
|
9
9
|
**acsUrl** | **String** | URL for the card-issuing bank’s authentication form that you receive when the card is enrolled. The value can be very large. | [optional]
|
|
10
10
|
**authenticationPath** | **String** | Indicates what displays to the customer during the authentication process. This field can contain one of these values: - `ADS`: (Card not enrolled) customer prompted to activate the card during the checkout process. - `ATTEMPTS`: (Attempts processing) Processing briefly displays before the checkout process is completed. - `ENROLLED`: (Card enrolled) the card issuer’s authentication window displays. - `UNKNOWN`: Card enrollment status cannot be determined. - `NOREDIRECT`: (Card not enrolled, authentication unavailable, or error occurred) nothing displays to the customer. The following values can be returned if you are using rules-based payer authentication. - `RIBA`: The card-issuing bank supports risk-based authentication, but whether the cardholder is likely to be challenged cannot be determined. - `RIBA_PASS`: The card-issuing bank supports risk-based authentication and it is likely that the cardholder will not be challenged to provide credentials, also known as _silent authentication_. For details about possible values, see `pa_enroll_authentication_path` field description and \"Rules-Based Payer Authentication\" in [CyberSource Payer Authentication Using the SCMP API.] (https://apps.cybersource.com/library/documentation/dev_guides/Payer_Authentication_SCMP_API/html/) | [optional]
|
|
11
11
|
**authorizationPayload** | **String** | The Base64 encoded JSON Payload of CB specific Authorization Values returned in the challenge Flow | [optional]
|
|
12
|
-
**authenticationTransactionId** | **String** | Payer authentication transaction identifier
|
|
12
|
+
**authenticationTransactionId** | **String** | Payer authentication transaction identifier is used to link the check enrollment and validate authentication messages. For Rupay, this field should be passed as request only for Resend OTP use case. | [optional]
|
|
13
13
|
**cardholderMessage** | **String** | Text provided by the ACS/Issuer to Cardholder during a Frictionless or Decoupled transaction.The Issuer can provide information to Cardholder. For example, “Additional authentication is needed for this transaction, please contact (Issuer Name) at xxx-xxx-xxxx.”. The Issuing Bank can optionally support this value. | [optional]
|
|
14
14
|
**cavv** | **String** | Unique identifier generated by the card-issuing bank for Visa, American Express, JCB, Diners Club, and Discover transactions after the customer is authenticated. The value is in base64. When you request the card authorization service, CyberSource automatically converts the value, not the field name, to the format required by your payment processor. | [optional]
|
|
15
15
|
**cavvAlgorithm** | **String** | Field that is returned only when the CAVV is generated, which occurs when paresStatus contains the values Y (successful authentication) or A (attempted authentication). If you use the ATOS processor, send the value of this field in the `cavv_algorithm` request field of the authorization service. This field contains one of these values: - `2`: Visa, American Express, JCB, Diners Club, and Discover - `3`: Mastercard | [optional]
|
|
@@ -7,5 +7,6 @@ Name | Type | Description | Notes
|
|
|
7
7
|
**discretionaryData** | **String** | Data defined by the issuer. The value for this reply field will probably be the same as the value that you submitted in the authorization request, but it is possible for the processor, issuer, or acquirer to modify the value. This field is supported only for Visa transactions on **CyberSource through VisaNet**. For details, see `issuer_additional_data` field description in the [Credit Card Services Using the SCMP API Guide.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) | [optional]
|
|
8
8
|
**countrySpecificDiscretionaryData** | **String** | Data defined by the issuer. This national use field contains two subfields for information unique to the processing of Visa transactions by members in Japan. This subfield contains the Katakana text to be printed on the receipt. For details, see `jpo_issuer_message` field description in the [Credit Card Services Using the SCMP API Guide.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) | [optional]
|
|
9
9
|
**responseCode** | **String** | Additional authorization code that must be printed on the receipt when returned by the processor. This value is generated by the processor and is returned only for a successful transaction. This reply field is supported only for these processors: - FDC Nashville Global - SIX | [optional]
|
|
10
|
+
**responseRaw** | **String** | issuerInformation.responseRaw is the raw processor auth response returned to merchant in CYBS auth response if auth request includes \"processingInformation.isReturnAuthRecordEnabled=true\". If supported by the gateway code, it is available to merchants who auth through CYBS and run their own settlement processing. | [optional]
|
|
10
11
|
|
|
11
12
|
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
# CyberSource.PtsV2PaymentsPost201ResponsePaymentInsightsInformation
|
|
2
|
+
|
|
3
|
+
## Properties
|
|
4
|
+
Name | Type | Description | Notes
|
|
5
|
+
------------ | ------------- | ------------- | -------------
|
|
6
|
+
**responseInsights** | [**PtsV2PaymentsPost201ResponsePaymentInsightsInformationResponseInsights**](PtsV2PaymentsPost201ResponsePaymentInsightsInformationResponseInsights.md) | | [optional]
|
|
7
|
+
|
|
8
|
+
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# CyberSource.PtsV2PaymentsPost201ResponsePaymentInsightsInformationResponseInsights
|
|
2
|
+
|
|
3
|
+
## Properties
|
|
4
|
+
Name | Type | Description | Notes
|
|
5
|
+
------------ | ------------- | ------------- | -------------
|
|
6
|
+
**category** | **String** | Categorization of response message from processor Possible Values: - `APPROVED` - `ISSUER_WILL_NEVER_APPROVE` - `ISSUER_CANT_APPROVE_AT_THIS_TIME` - `ISSUER_CANT_APPROVE_WITH_THESE_DETAILS` - `GENERIC_ERROR` - `OTHERS` - `MATCH_NOT_FOUND` | [optional]
|
|
7
|
+
**categoryCode** | **String** | Categorization Code of response message from processor Possible Values: - `01` : Issuer Will Never Approve - `02` : Issuer Can't Approve at this Time - `03` : Issuer Can't Approve with these Details - `04` : Generic Error - `98` : Others - `99` : Payment Insights Response Category Match Not Found | [optional]
|
|
8
|
+
|
|
9
|
+
|
|
@@ -14,7 +14,7 @@ Name | Type | Description | Notes
|
|
|
14
14
|
**strongAuthentication** | [**Ptsv2paymentsConsumerAuthenticationInformationStrongAuthentication**](Ptsv2paymentsConsumerAuthenticationInformationStrongAuthentication.md) | | [optional]
|
|
15
15
|
**directoryServerTransactionId** | **String** | The Directory Server Transaction ID is generated by the Mastercard Directory Server during the authentication transaction and passed back to the merchant with the authentication results. For Cybersource Through Visanet Gateway: The value for this field corresponds to the following data in the TC 33 capture file3: Record: CP01 TCR7, Position: 114-149, Field: MC AVV Verification—Directory Server Transaction ID | [optional]
|
|
16
16
|
**paSpecificationVersion** | **String** | This field contains 3DS version that was used for Secured Consumer Authentication (SCA). For example 3DS secure version 1.0.2 or 2.0.0 is used for Secured Consumer Authentication. For Cybersource Through Visanet Gateway: The value for this field corresponds to the following data in the TC 33 capture file3: Record: CP01 TCR7, Position: 113 , Field: MC AVV Verification—Program Protocol It will contain one of the following values: - `1` (3D Secure Version 1.0 (3DS 1.0)) - `2` (EMV 3-D Secure (3DS 2.0)) | [optional]
|
|
17
|
-
**authenticationType** | **String** | Indicates the type of authentication that will be used to challenge the card holder. Possible Values: 01 - Static 02 - Dynamic 03 - OOB (Out of Band) 04 - Decoupled **NOTE**: EMV 3-D Secure version 2.1.0 supports values 01-03. Version 2.2.0 supports values 01-04. Decoupled authentication is not supported at this time. | [optional]
|
|
17
|
+
**authenticationType** | **String** | Indicates the type of authentication that will be used to challenge the card holder. Possible Values: 01 - Static 02 - Dynamic 03 - OOB (Out of Band) 04 - Decoupled 20 - OTP hosted at merchant end. (Rupay S2S flow) **NOTE**: EMV 3-D Secure version 2.1.0 supports values 01-03. Version 2.2.0 supports values 01-04. Decoupled authentication is not supported at this time. | [optional]
|
|
18
18
|
**responseAccessToken** | **String** | JWT returned by the 3D Secure provider when the authentication is complete. Required for Hybrid integration if you use the Cybersource-generated access token. Note: Max. length of this field is 2048 characters. | [optional]
|
|
19
19
|
**acsTransactionId** | **String** | Unique transaction identifier assigned by the ACS to identify a single transaction. This field is supported for Cartes Bancaires Fast'R transactions on Credit Mutuel-CIC. | [optional]
|
|
20
20
|
**acsWindowSize** | **String** | An override field that a merchant can pass in to set the challenge window size to display to the end cardholder. The ACS (Active Control Server) will reply with content that is formatted appropriately to this window size to allow for the best user experience. The sizes are width x height in pixels of the window displayed in the cardholder browser window. 01 - 250x400 02 - 390x400 03 - 500x600 04 - 600x400 05 - Full page | [optional]
|
|
@@ -22,7 +22,7 @@ Name | Type | Description | Notes
|
|
|
22
22
|
**alternateAuthenticationDate** | **String** | Date and time in UTC of the cardholder authentication. Format: YYYYMMDDHHMM | [optional]
|
|
23
23
|
**alternateAuthenticationMethod** | **String** | Mechanism used by the cardholder to authenticate to the 3D Secure requestor. Possible values: - `01`: No authentication occurred - `02`: Login using merchant system credentials - `03`: Login using Federated ID - `04`: Login using issuer credentials - `05`: Login using third-party authenticator - `06`: Login using FIDO Authenticator | [optional]
|
|
24
24
|
**authenticationDate** | **String** | The date/time of the authentication at the 3DS servers. RISK update authorization service in auth request payload with value returned in `consumerAuthenticationInformation.alternateAuthenticationData` if merchant calls via CYBS or field can be provided by merchant in authorization request if calling an external 3DS provider. This field is supported for Cartes Bancaires Fast'R transactions on Credit Mutuel-CIC. Format: YYYYMMDDHHMMSS | [optional]
|
|
25
|
-
**authenticationTransactionId** | **String** | Payer authentication transaction identifier passed to link the check enrollment and validate authentication messages. **Note**: Required for Standard integration for enroll service. Required for Hybrid integration for validate service. | [optional]
|
|
25
|
+
**authenticationTransactionId** | **String** | Payer authentication transaction identifier passed to link the check enrollment and validate authentication messages.For Rupay,this is passed only in Re-Send OTP usecase. **Note**: Required for Standard integration, Rupay Seamless server to server integration for enroll service. Required for Hybrid integration for validate service. | [optional]
|
|
26
26
|
**challengeCancelCode** | **String** | An indicator as to why the transaction was canceled. Possible Values: - `01`: Cardholder selected Cancel. - `02`: Reserved for future EMVCo use (values invalid until defined by EMVCo). - `03`: Transaction Timed Out—Decoupled Authentication - `04`: Transaction timed out at ACS—other timeouts - `05`: Transaction Timed out at ACS - First CReq not received by ACS - `06`: Transaction Error - `07`: Unknown - `08`: Transaction Timed Out at SDK | [optional]
|
|
27
27
|
**challengeCode** | **String** | Possible values: - `01`: No preference - `02`: No challenge request - `03`: Challenge requested (3D Secure requestor preference) - `04`: Challenge requested (mandate) - `05`: No challenge requested (transactional risk analysis is already performed) - `06`: No challenge requested (Data share only) - `07`: No challenge requested (strong consumer authentication is already performed) - `08`: No challenge requested (utilize whitelist exemption if no challenge required) - `09`: Challenge requested (whitelist prompt requested if challenge required) **Note** This field will default to `01` on merchant configuration and can be overridden by the merchant. EMV 3D Secure version 2.1.0 supports values `01-04`. Version 2.2.0 supports values `01-09`. For details, see `pa_challenge_code` field description in [CyberSource Payer Authentication Using the SCMP API.] (https://apps.cybersource.com/library/documentation/dev_guides/Payer_Authentication_SCMP_API/html) | [optional]
|
|
28
28
|
**challengeStatus** | **String** | The `consumerAuthenticationInformation.challengeCode` indicates the authentication type/level, or challenge, that was presented to the cardholder at checkout by the merchant when calling the Carte Bancaire 3DS servers via CYBS RISK services. It conveys to the issuer the alternative authentication methods that the consumer used. | [optional]
|
|
@@ -17,5 +17,6 @@ Name | Type | Description | Notes
|
|
|
17
17
|
**startMonth** | **String** | Month of the start of the Maestro (UK Domestic) card validity period. Do not include the field, even with a blank value, if the card is not a Maestro (UK Domestic) card. `Format: MM`. Possible values: 01 through 12. **Note** The start date is not required for Maestro (UK Domestic) transactions. | [optional]
|
|
18
18
|
**startYear** | **String** | Year of the start of the Maestro (UK Domestic) card validity period. Do not include the field, even with a blank value, if the card is not a Maestro (UK Domestic) card. `Format: YYYY`. **Note** The start date is not required for Maestro (UK Domestic) transactions. | [optional]
|
|
19
19
|
**productName** | **String** | Name of the card product. Possible value: - BNDES This field is supported only for BNDES transactions on CyberSource through VisaNet. The value for this field corresponds to the following data in the TC 33 capture file5: - Record: CP07 TCR4 - Position: 115-120 - Field: Brazil Country Data | [optional]
|
|
20
|
+
**typeSelectionIndicator** | **String** | Flag that identifies how the card type was selected. Possible values: - 0: Card type was selected based on default acquirer settings. - 1: Customer selected the card type. | [optional]
|
|
20
21
|
|
|
21
22
|
|
|
@@ -7,11 +7,12 @@ Name | Type | Description | Notes
|
|
|
7
7
|
**expirationMonth** | **String** | One of two possible meanings: - The two-digit month in which a token expires. - The two-digit month in which a card expires. Format: `MM` Possible values: `01` through `12` **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (`01` through `12`) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_type=039`), if there is no expiration date on the card, use `12`.\\ **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. #### Samsung Pay and Apple Pay Month in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. For processor-specific information, see the `customer_cc_expmo` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) | [optional]
|
|
8
8
|
**expirationYear** | **String** | One of two possible meanings: - The four-digit year in which a token expires. - The four-digit year in which a card expires. Format: `YYYY` Possible values: `1900` through `3000` Data type: Non-negative integer **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (1900 through 3000) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_ type=039`), if there is no expiration date on the card, use `2021`. #### FDC Nashville Global and FDMS South You can send in 2 digits or 4 digits. When you send in 2 digits, they must be the last 2 digits of the year. #### Samsung Pay and Apple Pay Year in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. For processor-specific information, see the `customer_cc_expyr` or `token_expiration_year` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) | [optional]
|
|
9
9
|
**type** | **String** | Three-digit value that indicates the card type. **IMPORTANT** It is strongly recommended that you include the card type field in request messages even if it is optional for your processor and card type. Omitting the card type can cause the transaction to be processed with the wrong card type. Possible values: - `001`: Visa. For card-present transactions on all processors except SIX, the Visa Electron card type is processed the same way that the Visa debit card is processed. Use card type value `001` for Visa Electron. - `002`: Mastercard, Eurocard[^1], which is a European regional brand of Mastercard. - `003`: American Express - `004`: Discover - `005`: Diners Club - `006`: Carte Blanche[^1] - `007`: JCB[^1] - `014`: Enroute[^1] - `021`: JAL[^1] - `024`: Maestro (UK Domestic)[^1] - `031`: Delta[^1]: Use this value only for Ingenico ePayments. For other processors, use `001` for all Visa card types. - `033`: Visa Electron[^1]. Use this value only for Ingenico ePayments and SIX. For other processors, use `001` for all Visa card types. - `034`: Dankort[^1] - `036`: Cartes Bancaires[^1,4] - `037`: Carta Si[^1] - `039`: Encoded account number[^1] - `040`: UATP[^1] - `042`: Maestro (International)[^1] - `050`: Hipercard[^2,3] - `051`: Aura - `054`: Elo[^3] - `062`: China UnionPay [^1]: For this card type, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in your request for an authorization or a stand-alone credit. [^2]: For this card type on Cielo 3.0, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. This card type is not supported on Cielo 1.5. [^3]: For this card type on Getnet and Rede, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. [^4]: For this card type, you must include the `paymentInformation.card.type` in your request for any payer authentication services. #### Used by **Authorization** Required for Carte Blanche and JCB. Optional for all other card types. #### Card Present reply This field is included in the reply message when the client software that is installed on the POS terminal uses the token management service (TMS) to retrieve tokenized payment details. You must contact customer support to have your account enabled to receive these fields in the credit reply message. Returned by the Credit service. This reply field is only supported by the following processors: - American Express Direct - Credit Mutuel-CIC - FDC Nashville Global - OmniPay Direct - SIX #### Google Pay transactions For PAN-based Google Pay transactions, this field is returned in the API response. #### GPX This field only supports transactions from the following card types: - Visa - Mastercard - AMEX - Discover - Diners - JCB - Union Pay International | [optional]
|
|
10
|
-
**cryptogram** | **String** | This field
|
|
10
|
+
**cryptogram** | **String** | This field contains token information. | [optional]
|
|
11
11
|
**requestorId** | **String** | Value that identifies your business and indicates that the cardholder’s account number is tokenized. This value is assigned by the token service provider and is unique within the token service provider’s database. **Note** This field is supported only for **CyberSource through VisaNet** and **FDC Nashville Global**. #### PIN debit Optional field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
12
|
-
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
12
|
+
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: For Rupay and In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
13
13
|
**assuranceLevel** | **String** | Confidence level of the tokenization. This value is assigned by the token service provider. **Note** This field is supported only for **CyberSource through VisaNet** and **FDC Nashville Global**. Returned by PIN debit credit or PIN debit purchase. | [optional]
|
|
14
14
|
**storageMethod** | **String** | Type of technology used in the device to store token data. Possible values: - `001`: Secure Element (SE). Smart card or memory with restricted access and encryption to prevent data tampering. For storing payment credentials, a SE is tested against a set of requirements defined by the payment networks. **Note** This field is supported only for _FDC Compass_. - 002: Host Card Emulation (HCE). Emulation of a smart card by using software to create a virtual and exact representation of the card. Sensitive data is stored in a database that is hosted in the cloud. For storing payment credentials, a database must meet very stringent security requirements that exceed PCI DSS. **Note** This field is supported only for _FDC Compass_. | [optional]
|
|
15
15
|
**securityCode** | **String** | Card Verification Number (CVN). #### Ingenico ePayments Do not include this field when **commerceIndicator=recurring**. **Note** Ingenico ePayments was previously called _Global Collect_. For details, see `customer_cc_cv_number` field description in [Credit Card Services Using the SCMP API.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) | [optional]
|
|
16
|
+
**securityCodeIndicator** | **String** | Indicates whether a CVN code was sent. Possible values: - `0` (default): CVN service not requested. This default value is used when you do not include `securityCode` field in the request. - `1` (default): CVN service requested and supported. This default value is used when you include `securityCode` field in the request. - `2`: CVN on credit card is illegible. - `9`: CVN was not imprinted on credit card. #### FDMS Nashville Required for American Express cards; otherwise, optional. #### TSYS Acquiring Solutions Optional if `pointOfSaleInformation.entryMode=keyed`; otherwise, not used. #### All other processors Optional. | [optional]
|
|
16
17
|
|
|
17
18
|
|
|
@@ -8,6 +8,6 @@ Name | Type | Description | Notes
|
|
|
8
8
|
**cardSequenceNumber** | **String** | Number assigned to a specific card when two or more cards are associated with the same primary account number. This value enables issuers to distinguish among multiple cards that are linked to the same account. This value can also act as a tracking tool when reissuing cards. When this value is available, it is provided by the chip reader. When the chip reader does not provide this value, do not include this field in your request. **Note** Card present information about EMV applies only to credit card processing and PIN debit processing. All other card present information applies only to credit card processing. PIN debit processing is available only on CyberSource through VisaNet and FDC Nashville Global. #### Used by Authorization: Optional PIN Debit processing: Optional #### GPX This field only supports transactions from the following card types: - Visa - Mastercard - AMEX - Discover - Diners - JCB - Union Pay International | [optional]
|
|
9
9
|
**fallback** | **Boolean** | Indicates whether a fallback method was used to enter credit card information into the POS terminal. When a technical problem prevents a successful exchange of information between a chip card and a chip-capable terminal: 1. Swipe the card or key the credit card information into the POS terminal. 2. Use the pointOfSaleInformation.entryMode field to indicate whether the information was swiped or keyed. Possible values: - `true`: Fallback method was used. - `false` (default): Fallback method was not used. This field is supported only on American Express Direct, Chase Paymentech Solutions, CyberSource through VisaNet, FDC Nashville Global, GPN, JCN Gateway, OmniPay Direct, and SIX. | [optional]
|
|
10
10
|
**fallbackCondition** | **Number** | Reason for the EMV fallback transaction. An EMV fallback transaction occurs when an EMV transaction fails for one of these reasons: - Technical failure: the EMV terminal or EMV card cannot read and process chip data. - Empty candidate list failure: the EMV terminal does not have any applications in common with the EMV card. EMV terminals are coded to determine whether the terminal and EMV card have any applications in common. EMV terminals provide this information to you. Possible values: - `1`: Transaction was initiated with information from a magnetic stripe, and the previous transaction at the EMV terminal either used information from a successful chip read or it was not a chip transaction. - `2`: Transaction was initiated with information from a magnetic stripe, and the previous transaction at the EMV terminal was an EMV fallback transaction because the attempted chip read was unsuccessful. This field is supported only on **GPN** and **JCN Gateway**. **NOTE**: This field is required when an EMV transaction fails for a technical reason. Do not include this field when the EMV terminal does not have any applications in common with the EMV card. | [optional]
|
|
11
|
-
**isRepeat** | **
|
|
11
|
+
**isRepeat** | **Boolean** | #### Visa Platform Connect Value “true” indicates this transaction is intentionally duplicated . The field contains value “true” which indicates that merchant has intentionally duplicated single tap transaction. Merchant is intentionally sending a duplicate auth request for a single tap txn because the issuer requested a PIN. | [optional]
|
|
12
12
|
|
|
13
13
|
|
|
@@ -30,5 +30,6 @@ Name | Type | Description | Notes
|
|
|
30
30
|
**extendedCreditTotalCount** | **String** | A private national-use field submitted by acquirers and issuers in South Africa for South Africa-domestic (intra-country) authorizations and financial requests. Values for this field are 00 through 99. | [optional]
|
|
31
31
|
**networkRoutingOrder** | **String** | On PIN Debit Gateways: This U.S.-only field is optionally used by participants (merchants and acquirers) to specify the network access priority. VisaNet checks to determine if there are issuer routing preferences for any of the networks specified by the sharing group code. If an issuer preference exists for one of the specified debit networks, VisaNet makes a routing selection based on the issuer’s preference. If an issuer preference exists for more than one of the specified debit networks, or if no issuer preference exists, VisaNet makes a selection based on the acquirer’s routing priorities. #### PIN debit Priority order of the networks through which he transaction will be routed. Set this value to a series of one-character network codes in your preferred order. This is a list of the network codes: | Network | Code | | --- | --- | | Accel | E | | AFFN | U | | Alaska Option | 3 | | CU24 | C | | Interlink | G | | Maestro | 8 | | NETS | P | | NYCE | F | | Pulse | H | | Shazam | 7 | | Star | M | | Visa | V | For example, if the Star network is your first preference and Pulse is your second preference, set this field to a value of `MH`. When you do not include this value in your PIN debit request, the list of network codes from your account is used. **Note** This field is supported only for businesses located in the U.S. Optional field for PIN debit credit or PIN debit purchase. | [optional]
|
|
32
32
|
**payByPointsIndicator** | **Boolean** | Flag that indicates if the transaction is pay by points transaction true: Transaction uses loyalty points false: Transaction does not use loyalty points Default: false | [optional]
|
|
33
|
+
**isReturnAuthRecordEnabled** | **Boolean** | Flag that indicates the functionality we are having for merchants for which auth is done through Cybersource but settlement is done by themselves. true: functionality is supported. Processor should send raw processor auth response to Merchant. false: functionality is not supported. Default: false | [optional]
|
|
33
34
|
|
|
34
35
|
|
|
@@ -5,7 +5,7 @@ Name | Type | Description | Notes
|
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
6
|
**type** | **String** | This field indicates whether the transaction is a merchant-initiated transaction or customer-initiated transaction. Valid values: - **customer** - **merchant** | [optional]
|
|
7
7
|
**credentialStoredOnFile** | **Boolean** | Indicates to the issuing bank two things: - The merchant has received consent from the cardholder to store their card details on file - The merchant wants the issuing bank to check out the card details before the merchant initiates their first transaction for this cardholder. The purpose of the merchant-initiated transaction is to ensure that the cardholder’s credentials are valid (that the card is not stolen or has restrictions) and that the card details are good to be stored on the merchant’s file for future transactions. Valid values: - `true` means merchant will use this transaction to store payment credentials for follow-up merchant-initiated transactions. - `false` means merchant will not use this transaction to store payment credentials for follow-up merchant-initiated transactions. For details, see `subsequent_auth_first` field description in the [Credit Card Services Using the SCMP API Guide.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) **NOTE:** The value for this field does not correspond to any data in the TC 33 capture file5. This field is supported only for Visa transactions on CyberSource through VisaNet. | [optional]
|
|
8
|
-
**storedCredentialUsed** | **
|
|
8
|
+
**storedCredentialUsed** | **Boolean** | Indicates to an issuing bank whether a merchant-initiated transaction came from a card that was already stored on file. Possible values: - **true** means the merchant-initiated transaction came from a card that was already stored on file. - **false** means the merchant-initiated transaction came from a card that was not stored on file. | [optional]
|
|
9
9
|
**merchantInitiatedTransaction** | [**Ptsv2paymentsProcessingInformationAuthorizationOptionsInitiatorMerchantInitiatedTransaction**](Ptsv2paymentsProcessingInformationAuthorizationOptionsInitiatorMerchantInitiatedTransaction.md) | | [optional]
|
|
10
10
|
|
|
11
11
|
|
|
@@ -3,6 +3,6 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**storedCredentialUsed** | **
|
|
6
|
+
**storedCredentialUsed** | **Boolean** | Indicates to an issuing bank whether a merchant-initiated transaction came from a card that was already stored on file. Possible values: - **true** means the merchant-initiated transaction came from a card that was already stored on file. - **false** means the merchant-initiated transaction came from a card that was not stored on file. | [optional]
|
|
7
7
|
|
|
8
8
|
|
|
@@ -25,5 +25,6 @@ Name | Type | Description | Notes
|
|
|
25
25
|
**representmentCPTime** | **Date** | Representment CP Date | [optional]
|
|
26
26
|
**applications** | **String** | ICS Request Applications | [optional]
|
|
27
27
|
**eventRequestedTime** | **Date** | Event Request Date | [optional]
|
|
28
|
+
**preDisputeFlag** | **String** | Pre Dispute Flag | [optional]
|
|
28
29
|
|
|
29
30
|
|
|
@@ -7,6 +7,9 @@ Name | Type | Description | Notes
|
|
|
7
7
|
**acsTransactionId** | **String** | Unique transaction identifier assigned by the ACS to identify a single transaction. | [optional]
|
|
8
8
|
**authenticationResult** | **String** | Raw authentication data that comes from the cardissuing bank. Primary authentication field that indicates if authentication was successful and if liability shift occurred. You should examine first the result of this field. This field contains one of these values: - `-1`: Invalid PARes. - `0`: Successful validation. - `1`: Cardholder is not participating, but the attempt to authenticate was recorded. - `6`: Issuer unable to perform authentication. - `9`: Cardholder did not complete authentication. | [optional]
|
|
9
9
|
**authenticationStatusMsg** | **String** | Message that explains the authenticationResult reply field. | [optional]
|
|
10
|
+
**authenticationTransactionId** | **String** | Payer authentication transaction identifier is used to link the check enrollment and validate authentication messages. For Rupay, this field should be passed as request only for Resend OTP use case. | [optional]
|
|
11
|
+
**authenticationTransactionContextId** | **String** | Payer authentication transaction identifier passed to link the validation and authorization calls. | [optional]
|
|
12
|
+
**transactionToken** | **String** | Web based token used to authenticate consumer with Rupay authentication provider. | [optional]
|
|
10
13
|
**authorizationPayload** | **String** | The Base64 encoded JSON Payload of CB specific Authorization Values returned in the challenge Flow | [optional]
|
|
11
14
|
**cavv** | **String** | Unique identifier generated by the card-issuing bank for Visa, American Express, JCB, Diners Club, and Discover transactions after the customer is authenticated. The value is in base64. When you request the card authorization service, CyberSource automatically converts the value, not the field name, to the format required by your payment processor. | [optional]
|
|
12
15
|
**cavvAlgorithm** | **String** | Field that is returned only when the CAVV is generated, which occurs when paresStatus contains the values Y (successful authentication) or A (attempted authentication). If you use the ATOS processor, send the value of this field in the `cavv_algorithm` request field of the authorization service. This field contains one of these values: - `2`: Visa, American Express, JCB, Diners Club, and Discover - `3`: Mastercard | [optional]
|
|
@@ -9,7 +9,10 @@ Name | Type | Description | Notes
|
|
|
9
9
|
**acsUrl** | **String** | URL for the card-issuing bank’s authentication form that you receive when the card is enrolled. The value can be very large. | [optional]
|
|
10
10
|
**authenticationPath** | **String** | Indicates what displays to the customer during the authentication process. This field can contain one of these values: - `ADS`: (Card not enrolled) customer prompted to activate the card during the checkout process. - `ATTEMPTS`: (Attempts processing) Processing briefly displays before the checkout process is completed. - `ENROLLED`: (Card enrolled) the card issuer’s authentication window displays. - `UNKNOWN`: Card enrollment status cannot be determined. - `NOREDIRECT`: (Card not enrolled, authentication unavailable, or error occurred) nothing displays to the customer. The following values can be returned if you are using rules-based payer authentication. - `RIBA`: The card-issuing bank supports risk-based authentication, but whether the cardholder is likely to be challenged cannot be determined. - `RIBA_PASS`: The card-issuing bank supports risk-based authentication and it is likely that the cardholder will not be challenged to provide credentials, also known as _silent authentication_. For details about possible values, see `pa_enroll_authentication_path` field description and \"Rules-Based Payer Authentication\" in [CyberSource Payer Authentication Using the SCMP API.] (https://apps.cybersource.com/library/documentation/dev_guides/Payer_Authentication_SCMP_API/html/) | [optional]
|
|
11
11
|
**authorizationPayload** | **String** | The Base64 encoded JSON Payload of CB specific Authorization Values returned in the challenge Flow | [optional]
|
|
12
|
-
**
|
|
12
|
+
**authenticationType** | **String** | Indicates the type of authentication that will be used to challenge the card holder. Possible Values: 01 - Static 02 - Dynamic 03 - OOB (Out of Band) 04 - Decoupled 20 - OTP hosted at merchant end. (Rupay S2S flow) **NOTE**: EMV 3-D Secure version 2.1.0 supports values 01-03. Version 2.2.0 supports values 01-04. Decoupled authentication is not supported at this time. | [optional]
|
|
13
|
+
**authenticationTransactionId** | **String** | Payer authentication transaction identifier is used to link the check enrollment and validate authentication messages. For Rupay, this field should be passed as request only for Resend OTP use case. | [optional]
|
|
14
|
+
**authenticationTransactionContextId** | **String** | Payer authentication transaction identifier passed to link the validation and authorization calls. | [optional]
|
|
15
|
+
**validityPeriod** | **Number** | Describes validity of OTP in minutes for incoming transaction. . | [optional]
|
|
13
16
|
**cardholderMessage** | **String** | Text provided by the ACS/Issuer to Cardholder during a Frictionless or Decoupled transaction.The Issuer can provide information to Cardholder. For example, “Additional authentication is needed for this transaction, please contact (Issuer Name) at xxx-xxx-xxxx.”. The Issuing Bank can optionally support this value. | [optional]
|
|
14
17
|
**cavv** | **String** | Unique identifier generated by the card-issuing bank for Visa, American Express, JCB, Diners Club, and Discover transactions after the customer is authenticated. The value is in base64. When you request the card authorization service, CyberSource automatically converts the value, not the field name, to the format required by your payment processor. | [optional]
|
|
15
18
|
**cavvAlgorithm** | **String** | Field that is returned only when the CAVV is generated, which occurs when paresStatus contains the values Y (successful authentication) or A (attempted authentication). If you use the ATOS processor, send the value of this field in the `cavv_algorithm` request field of the authorization service. This field contains one of these values: - `2`: Visa, American Express, JCB, Diners Club, and Discover - `3`: Mastercard | [optional]
|
|
@@ -3,8 +3,10 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**authenticationTransactionId** | **String** | Payer authentication transaction identifier passed to link the check enrollment and validate authentication messages. **Note**: Required for Standard integration for enroll service. Required for Hybrid integration for validate service. | [optional]
|
|
7
|
-
**
|
|
6
|
+
**authenticationTransactionId** | **String** | Payer authentication transaction identifier passed to link the check enrollment and validate authentication messages.For Rupay,this is passed only in Re-Send OTP usecase. **Note**: Required for Standard integration, Rupay Seamless server to server integration for enroll service. Required for Hybrid integration for validate service. | [optional]
|
|
7
|
+
**authenticationTransactionContext** | **String** | Authentication transaction context is used as a unique identifier to link enroll and validate call. | [optional]
|
|
8
|
+
**otpToken** | **String** | OTP entered by the card holder. | [optional]
|
|
9
|
+
**authenticationType** | **String** | Indicates the type of authentication that will be used to challenge the card holder. Possible Values: 01 - Static 02 - Dynamic 03 - OOB (Out of Band) 04 - Decoupled 20 - OTP hosted at merchant end. (Rupay S2S flow) **NOTE**: EMV 3-D Secure version 2.1.0 supports values 01-03. Version 2.2.0 supports values 01-04. Decoupled authentication is not supported at this time. | [optional]
|
|
8
10
|
**effectiveAuthenticationType** | **String** | This field describes the type of 3DS transaction flow that took place. It can be one of three possible flows; CH - Challenge FR - Frictionless FD - Frictionless with delegation, (challenge not generated by the issuer but by the scheme on behalf of the issuer). | [optional]
|
|
9
11
|
**responseAccessToken** | **String** | JWT returned by the 3D Secure provider when the authentication is complete. Required for Hybrid integration if you use the Cybersource-generated access token. Note: Max. length of this field is 2048 characters. | [optional]
|
|
10
12
|
**signedParesStatusReason** | **String** | Provides additional information as to why the PAResStatus has a specific value. | [optional]
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
6
|
+
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: For Rupay and In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
7
7
|
**type** | **String** | Three-digit value that indicates the card type. **IMPORTANT** It is strongly recommended that you include the card type field in request messages even if it is optional for your processor and card type. Omitting the card type can cause the transaction to be processed with the wrong card type. Possible values: - `001`: Visa. For card-present transactions on all processors except SIX, the Visa Electron card type is processed the same way that the Visa debit card is processed. Use card type value `001` for Visa Electron. - `002`: Mastercard, Eurocard[^1], which is a European regional brand of Mastercard. - `003`: American Express - `004`: Discover - `005`: Diners Club - `006`: Carte Blanche[^1] - `007`: JCB[^1] - `014`: Enroute[^1] - `021`: JAL[^1] - `024`: Maestro (UK Domestic)[^1] - `031`: Delta[^1]: Use this value only for Ingenico ePayments. For other processors, use `001` for all Visa card types. - `033`: Visa Electron[^1]. Use this value only for Ingenico ePayments and SIX. For other processors, use `001` for all Visa card types. - `034`: Dankort[^1] - `036`: Cartes Bancaires[^1,4] - `037`: Carta Si[^1] - `039`: Encoded account number[^1] - `040`: UATP[^1] - `042`: Maestro (International)[^1] - `050`: Hipercard[^2,3] - `051`: Aura - `054`: Elo[^3] - `062`: China UnionPay [^1]: For this card type, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in your request for an authorization or a stand-alone credit. [^2]: For this card type on Cielo 3.0, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. This card type is not supported on Cielo 1.5. [^3]: For this card type on Getnet and Rede, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. [^4]: For this card type, you must include the `paymentInformation.card.type` in your request for any payer authentication services. #### Used by **Authorization** Required for Carte Blanche and JCB. Optional for all other card types. #### Card Present reply This field is included in the reply message when the client software that is installed on the POS terminal uses the token management service (TMS) to retrieve tokenized payment details. You must contact customer support to have your account enabled to receive these fields in the credit reply message. Returned by the Credit service. This reply field is only supported by the following processors: - American Express Direct - Credit Mutuel-CIC - FDC Nashville Global - OmniPay Direct - SIX #### Google Pay transactions For PAN-based Google Pay transactions, this field is returned in the API response. #### GPX This field only supports transactions from the following card types: - Visa - Mastercard - AMEX - Discover - Diners - JCB - Union Pay International | [optional]
|
|
8
8
|
**expirationMonth** | **String** | One of two possible meanings: - The two-digit month in which a token expires. - The two-digit month in which a card expires. Format: `MM` Possible values: `01` through `12` **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (`01` through `12`) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_type=039`), if there is no expiration date on the card, use `12`.\\ **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. #### Samsung Pay and Apple Pay Month in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. For processor-specific information, see the `customer_cc_expmo` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) | [optional]
|
|
9
9
|
**expirationYear** | **String** | One of two possible meanings: - The four-digit year in which a token expires. - The four-digit year in which a card expires. Format: `YYYY` Possible values: `1900` through `3000` Data type: Non-negative integer **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (1900 through 3000) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_ type=039`), if there is no expiration date on the card, use `2021`. #### FDC Nashville Global and FDMS South You can send in 2 digits or 4 digits. When you send in 2 digits, they must be the last 2 digits of the year. #### Samsung Pay and Apple Pay Year in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. For processor-specific information, see the `customer_cc_expyr` or `token_expiration_year` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) | [optional]
|
|
@@ -3,10 +3,12 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. |
|
|
6
|
+
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: For Rupay and In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. |
|
|
7
7
|
**type** | **String** | Three-digit value that indicates the card type. **IMPORTANT** It is strongly recommended that you include the card type field in request messages even if it is optional for your processor and card type. Omitting the card type can cause the transaction to be processed with the wrong card type. Possible values: - `001`: Visa. For card-present transactions on all processors except SIX, the Visa Electron card type is processed the same way that the Visa debit card is processed. Use card type value `001` for Visa Electron. - `002`: Mastercard, Eurocard[^1], which is a European regional brand of Mastercard. - `003`: American Express - `004`: Discover - `005`: Diners Club - `006`: Carte Blanche[^1] - `007`: JCB[^1] - `014`: Enroute[^1] - `021`: JAL[^1] - `024`: Maestro (UK Domestic)[^1] - `031`: Delta[^1]: Use this value only for Ingenico ePayments. For other processors, use `001` for all Visa card types. - `033`: Visa Electron[^1]. Use this value only for Ingenico ePayments and SIX. For other processors, use `001` for all Visa card types. - `034`: Dankort[^1] - `036`: Cartes Bancaires[^1,4] - `037`: Carta Si[^1] - `039`: Encoded account number[^1] - `040`: UATP[^1] - `042`: Maestro (International)[^1] - `050`: Hipercard[^2,3] - `051`: Aura - `054`: Elo[^3] - `062`: China UnionPay [^1]: For this card type, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in your request for an authorization or a stand-alone credit. [^2]: For this card type on Cielo 3.0, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. This card type is not supported on Cielo 1.5. [^3]: For this card type on Getnet and Rede, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. [^4]: For this card type, you must include the `paymentInformation.card.type` in your request for any payer authentication services. #### Used by **Authorization** Required for Carte Blanche and JCB. Optional for all other card types. #### Card Present reply This field is included in the reply message when the client software that is installed on the POS terminal uses the token management service (TMS) to retrieve tokenized payment details. You must contact customer support to have your account enabled to receive these fields in the credit reply message. Returned by the Credit service. This reply field is only supported by the following processors: - American Express Direct - Credit Mutuel-CIC - FDC Nashville Global - OmniPay Direct - SIX #### Google Pay transactions For PAN-based Google Pay transactions, this field is returned in the API response. #### GPX This field only supports transactions from the following card types: - Visa - Mastercard - AMEX - Discover - Diners - JCB - Union Pay International |
|
|
8
8
|
**expirationMonth** | **String** | One of two possible meanings: - The two-digit month in which a token expires. - The two-digit month in which a card expires. Format: `MM` Possible values: `01` through `12` **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (`01` through `12`) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_type=039`), if there is no expiration date on the card, use `12`.\\ **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. #### Samsung Pay and Apple Pay Month in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. For processor-specific information, see the `customer_cc_expmo` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) |
|
|
9
9
|
**expirationYear** | **String** | One of two possible meanings: - The four-digit year in which a token expires. - The four-digit year in which a card expires. Format: `YYYY` Possible values: `1900` through `3000` Data type: Non-negative integer **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (1900 through 3000) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_ type=039`), if there is no expiration date on the card, use `2021`. #### FDC Nashville Global and FDMS South You can send in 2 digits or 4 digits. When you send in 2 digits, they must be the last 2 digits of the year. #### Samsung Pay and Apple Pay Year in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. For processor-specific information, see the `customer_cc_expyr` or `token_expiration_year` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) |
|
|
10
|
+
**cryptogram** | **String** | This field contains token information. |
|
|
11
|
+
**securityCode** | **String** | Card Verification Number (CVN). #### Ingenico ePayments Do not include this field when **commerceIndicator=recurring**. **Note** Ingenico ePayments was previously called _Global Collect_. For details, see `customer_cc_cv_number` field description in [Credit Card Services Using the SCMP API.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) |
|
|
10
12
|
**_number** | **String** | Customer’s payment network token value. |
|
|
11
13
|
|
|
12
14
|
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. |
|
|
6
|
+
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: For Rupay and In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. |
|
|
7
7
|
**type** | **String** | Three-digit value that indicates the card type. **IMPORTANT** It is strongly recommended that you include the card type field in request messages even if it is optional for your processor and card type. Omitting the card type can cause the transaction to be processed with the wrong card type. Possible values: - `001`: Visa. For card-present transactions on all processors except SIX, the Visa Electron card type is processed the same way that the Visa debit card is processed. Use card type value `001` for Visa Electron. - `002`: Mastercard, Eurocard[^1], which is a European regional brand of Mastercard. - `003`: American Express - `004`: Discover - `005`: Diners Club - `006`: Carte Blanche[^1] - `007`: JCB[^1] - `014`: Enroute[^1] - `021`: JAL[^1] - `024`: Maestro (UK Domestic)[^1] - `031`: Delta[^1]: Use this value only for Ingenico ePayments. For other processors, use `001` for all Visa card types. - `033`: Visa Electron[^1]. Use this value only for Ingenico ePayments and SIX. For other processors, use `001` for all Visa card types. - `034`: Dankort[^1] - `036`: Cartes Bancaires[^1,4] - `037`: Carta Si[^1] - `039`: Encoded account number[^1] - `040`: UATP[^1] - `042`: Maestro (International)[^1] - `050`: Hipercard[^2,3] - `051`: Aura - `054`: Elo[^3] - `062`: China UnionPay [^1]: For this card type, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in your request for an authorization or a stand-alone credit. [^2]: For this card type on Cielo 3.0, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. This card type is not supported on Cielo 1.5. [^3]: For this card type on Getnet and Rede, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. [^4]: For this card type, you must include the `paymentInformation.card.type` in your request for any payer authentication services. #### Used by **Authorization** Required for Carte Blanche and JCB. Optional for all other card types. #### Card Present reply This field is included in the reply message when the client software that is installed on the POS terminal uses the token management service (TMS) to retrieve tokenized payment details. You must contact customer support to have your account enabled to receive these fields in the credit reply message. Returned by the Credit service. This reply field is only supported by the following processors: - American Express Direct - Credit Mutuel-CIC - FDC Nashville Global - OmniPay Direct - SIX #### Google Pay transactions For PAN-based Google Pay transactions, this field is returned in the API response. #### GPX This field only supports transactions from the following card types: - Visa - Mastercard - AMEX - Discover - Diners - JCB - Union Pay International |
|
|
8
8
|
**expirationMonth** | **String** | One of two possible meanings: - The two-digit month in which a token expires. - The two-digit month in which a card expires. Format: `MM` Possible values: `01` through `12` **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (`01` through `12`) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_type=039`), if there is no expiration date on the card, use `12`.\\ **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. #### Samsung Pay and Apple Pay Month in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. For processor-specific information, see the `customer_cc_expmo` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) |
|
|
9
9
|
**expirationYear** | **String** | One of two possible meanings: - The four-digit year in which a token expires. - The four-digit year in which a card expires. Format: `YYYY` Possible values: `1900` through `3000` Data type: Non-negative integer **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (1900 through 3000) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_ type=039`), if there is no expiration date on the card, use `2021`. #### FDC Nashville Global and FDMS South You can send in 2 digits or 4 digits. When you send in 2 digits, they must be the last 2 digits of the year. #### Samsung Pay and Apple Pay Year in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. For processor-specific information, see the `customer_cc_expyr` or `token_expiration_year` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) |
|
|
@@ -4,13 +4,14 @@
|
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
6
|
**strongAuthentication** | [**Riskv1decisionsConsumerAuthenticationInformationStrongAuthentication**](Riskv1decisionsConsumerAuthenticationInformationStrongAuthentication.md) | | [optional]
|
|
7
|
-
**authenticationType** | **String** | Indicates the type of authentication that will be used to challenge the card holder. Possible Values: 01 - Static 02 - Dynamic 03 - OOB (Out of Band) 04 - Decoupled **NOTE**: EMV 3-D Secure version 2.1.0 supports values 01-03. Version 2.2.0 supports values 01-04. Decoupled authentication is not supported at this time. | [optional]
|
|
7
|
+
**authenticationType** | **String** | Indicates the type of authentication that will be used to challenge the card holder. Possible Values: 01 - Static 02 - Dynamic 03 - OOB (Out of Band) 04 - Decoupled 20 - OTP hosted at merchant end. (Rupay S2S flow) **NOTE**: EMV 3-D Secure version 2.1.0 supports values 01-03. Version 2.2.0 supports values 01-04. Decoupled authentication is not supported at this time. | [optional]
|
|
8
8
|
**acsWindowSize** | **String** | An override field that a merchant can pass in to set the challenge window size to display to the end cardholder. The ACS (Active Control Server) will reply with content that is formatted appropriately to this window size to allow for the best user experience. The sizes are width x height in pixels of the window displayed in the cardholder browser window. 01 - 250x400 02 - 390x400 03 - 500x600 04 - 600x400 05 - Full page | [optional]
|
|
9
9
|
**alternateAuthenticationData** | **String** | Data that documents and supports a specific authentication process. | [optional]
|
|
10
10
|
**alternateAuthenticationDate** | **String** | Date and time in UTC of the cardholder authentication. Format: YYYYMMDDHHMM | [optional]
|
|
11
11
|
**alternateAuthenticationMethod** | **String** | Mechanism used by the cardholder to authenticate to the 3D Secure requestor. Possible values: - `01`: No authentication occurred - `02`: Login using merchant system credentials - `03`: Login using Federated ID - `04`: Login using issuer credentials - `05`: Login using third-party authenticator - `06`: Login using FIDO Authenticator | [optional]
|
|
12
12
|
**authenticationDate** | **String** | The date/time of the authentication at the 3DS servers. RISK update authorization service in auth request payload with value returned in `consumerAuthenticationInformation.alternateAuthenticationData` if merchant calls via CYBS or field can be provided by merchant in authorization request if calling an external 3DS provider. This field is supported for Cartes Bancaires Fast'R transactions on Credit Mutuel-CIC. Format: YYYYMMDDHHMMSS | [optional]
|
|
13
|
-
**authenticationTransactionId** | **String** | Payer authentication transaction identifier passed to link the check enrollment and validate authentication messages. **Note**: Required for Standard integration for enroll service. Required for Hybrid integration for validate service. | [optional]
|
|
13
|
+
**authenticationTransactionId** | **String** | Payer authentication transaction identifier passed to link the check enrollment and validate authentication messages.For Rupay,this is passed only in Re-Send OTP usecase. **Note**: Required for Standard integration, Rupay Seamless server to server integration for enroll service. Required for Hybrid integration for validate service. | [optional]
|
|
14
|
+
**transactionFlowIndicator** | **Number** | This field is only applicable to Rupay and is optional. Merchant will have to pass a valid value from 01 through 07 which indicates the transaction flow. Below are the possible values. 01:NW – Transaction performed at domestic merchant. 02:TW - Transaction performed at domestic merchant along with Token provisioning. 03:IT – Transaction performed at International merchant. 04:AT- Authentication Transaction Only. 05:AW- Authentication transaction for provisioning. 06:DI- Domestic InApp Transaction. 07:II- International InApp transaction. | [optional]
|
|
14
15
|
**challengeCancelCode** | **String** | An indicator as to why the transaction was canceled. Possible Values: - `01`: Cardholder selected Cancel. - `02`: Reserved for future EMVCo use (values invalid until defined by EMVCo). - `03`: Transaction Timed Out—Decoupled Authentication - `04`: Transaction timed out at ACS—other timeouts - `05`: Transaction Timed out at ACS - First CReq not received by ACS - `06`: Transaction Error - `07`: Unknown - `08`: Transaction Timed Out at SDK | [optional]
|
|
15
16
|
**challengeCode** | **String** | Possible values: - `01`: No preference - `02`: No challenge request - `03`: Challenge requested (3D Secure requestor preference) - `04`: Challenge requested (mandate) - `05`: No challenge requested (transactional risk analysis is already performed) - `06`: No challenge requested (Data share only) - `07`: No challenge requested (strong consumer authentication is already performed) - `08`: No challenge requested (utilize whitelist exemption if no challenge required) - `09`: Challenge requested (whitelist prompt requested if challenge required) **Note** This field will default to `01` on merchant configuration and can be overridden by the merchant. EMV 3D Secure version 2.1.0 supports values `01-04`. Version 2.2.0 supports values `01-09`. For details, see `pa_challenge_code` field description in [CyberSource Payer Authentication Using the SCMP API.] (https://apps.cybersource.com/library/documentation/dev_guides/Payer_Authentication_SCMP_API/html) | [optional]
|
|
16
17
|
**challengeStatus** | **String** | The `consumerAuthenticationInformation.challengeCode` indicates the authentication type/level, or challenge, that was presented to the cardholder at checkout by the merchant when calling the Carte Bancaire 3DS servers via CYBS RISK services. It conveys to the issuer the alternative authentication methods that the consumer used. | [optional]
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
6
|
+
**transactionType** | **String** | Type of transaction that provided the token data. This value does not specify the token service provider; it specifies the entity that provided you with information about the token. Possible value: - `2`: Near-field communication (NFC) transaction. The customer’s mobile device provided the token data for a contactless EMV transaction. For recurring transactions, use this value if the original transaction was a contactless EMV transaction. #### Visa Platform Connect - `1`: For Rupay and In App tokenization. Example: InApp apple pay. - `3`: Card/Credential On File Tokenization. **NOTE** No CyberSource through VisaNet acquirers support EMV at this time. Required field for PIN debit credit or PIN debit purchase transactions that use payment network tokens; otherwise, not used. | [optional]
|
|
7
7
|
**type** | **String** | Three-digit value that indicates the card type. **IMPORTANT** It is strongly recommended that you include the card type field in request messages even if it is optional for your processor and card type. Omitting the card type can cause the transaction to be processed with the wrong card type. Possible values: - `001`: Visa. For card-present transactions on all processors except SIX, the Visa Electron card type is processed the same way that the Visa debit card is processed. Use card type value `001` for Visa Electron. - `002`: Mastercard, Eurocard[^1], which is a European regional brand of Mastercard. - `003`: American Express - `004`: Discover - `005`: Diners Club - `006`: Carte Blanche[^1] - `007`: JCB[^1] - `014`: Enroute[^1] - `021`: JAL[^1] - `024`: Maestro (UK Domestic)[^1] - `031`: Delta[^1]: Use this value only for Ingenico ePayments. For other processors, use `001` for all Visa card types. - `033`: Visa Electron[^1]. Use this value only for Ingenico ePayments and SIX. For other processors, use `001` for all Visa card types. - `034`: Dankort[^1] - `036`: Cartes Bancaires[^1,4] - `037`: Carta Si[^1] - `039`: Encoded account number[^1] - `040`: UATP[^1] - `042`: Maestro (International)[^1] - `050`: Hipercard[^2,3] - `051`: Aura - `054`: Elo[^3] - `062`: China UnionPay [^1]: For this card type, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in your request for an authorization or a stand-alone credit. [^2]: For this card type on Cielo 3.0, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. This card type is not supported on Cielo 1.5. [^3]: For this card type on Getnet and Rede, you must include the `paymentInformation.card.type` or `paymentInformation.tokenizedCard.type` field in a request for an authorization or a stand-alone credit. [^4]: For this card type, you must include the `paymentInformation.card.type` in your request for any payer authentication services. #### Used by **Authorization** Required for Carte Blanche and JCB. Optional for all other card types. #### Card Present reply This field is included in the reply message when the client software that is installed on the POS terminal uses the token management service (TMS) to retrieve tokenized payment details. You must contact customer support to have your account enabled to receive these fields in the credit reply message. Returned by the Credit service. This reply field is only supported by the following processors: - American Express Direct - Credit Mutuel-CIC - FDC Nashville Global - OmniPay Direct - SIX #### Google Pay transactions For PAN-based Google Pay transactions, this field is returned in the API response. #### GPX This field only supports transactions from the following card types: - Visa - Mastercard - AMEX - Discover - Diners - JCB - Union Pay International | [optional]
|
|
8
8
|
**_number** | **String** | Customer’s payment network token value. | [optional]
|
|
9
9
|
**expirationMonth** | **String** | One of two possible meanings: - The two-digit month in which a token expires. - The two-digit month in which a card expires. Format: `MM` Possible values: `01` through `12` **NOTE** The meaning of this field is dependent on the payment processor that is returning the value in an authorization reply. Please see the processor-specific details below. #### Barclays and Streamline For Maestro (UK Domestic) and Maestro (International) cards on Barclays and Streamline, this must be a valid value (`01` through `12`) but is not required to be a valid expiration date. In other words, an expiration date that is in the past does not cause CyberSource to reject your request. However, an invalid expiration date might cause the issuer to reject your request. #### Encoded Account Numbers For encoded account numbers (`card_type=039`), if there is no expiration date on the card, use `12`.\\ **Important** It is your responsibility to determine whether a field is required for the transaction you are requesting. #### Samsung Pay and Apple Pay Month in which the token expires. CyberSource includes this field in the reply message when it decrypts the payment blob for the tokenized transaction. For processor-specific information, see the `customer_cc_expmo` field in [Credit Card Services Using the SCMP API.](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html) | [optional]
|
|
@@ -55,7 +55,7 @@ No authorization required
|
|
|
55
55
|
|
|
56
56
|
### HTTP request headers
|
|
57
57
|
|
|
58
|
-
- **Content-Type**:
|
|
58
|
+
- **Content-Type**: */*;charset=utf-8
|
|
59
59
|
- **Accept**: application/xml, text/csv, application/pdf
|
|
60
60
|
|
|
61
61
|
<a name="getFileDetail"></a>
|
|
@@ -110,6 +110,6 @@ No authorization required
|
|
|
110
110
|
|
|
111
111
|
### HTTP request headers
|
|
112
112
|
|
|
113
|
-
- **Content-Type**:
|
|
113
|
+
- **Content-Type**: */*;charset=utf-8
|
|
114
114
|
- **Accept**: application/hal+json
|
|
115
115
|
|
|
@@ -21,6 +21,7 @@ Name | Type | Description | Notes
|
|
|
21
21
|
**merchantInformation** | [**TssV2TransactionsGet200ResponseMerchantInformation**](TssV2TransactionsGet200ResponseMerchantInformation.md) | | [optional]
|
|
22
22
|
**orderInformation** | [**TssV2TransactionsGet200ResponseOrderInformation**](TssV2TransactionsGet200ResponseOrderInformation.md) | | [optional]
|
|
23
23
|
**paymentInformation** | [**TssV2TransactionsGet200ResponsePaymentInformation**](TssV2TransactionsGet200ResponsePaymentInformation.md) | | [optional]
|
|
24
|
+
**paymentInsightsInformation** | [**PtsV2PaymentsPost201ResponsePaymentInsightsInformation**](PtsV2PaymentsPost201ResponsePaymentInsightsInformation.md) | | [optional]
|
|
24
25
|
**processingInformation** | [**TssV2TransactionsGet200ResponseProcessingInformation**](TssV2TransactionsGet200ResponseProcessingInformation.md) | | [optional]
|
|
25
26
|
**processorInformation** | [**TssV2TransactionsGet200ResponseProcessorInformation**](TssV2TransactionsGet200ResponseProcessorInformation.md) | | [optional]
|
|
26
27
|
**pointOfSaleInformation** | [**TssV2TransactionsGet200ResponsePointOfSaleInformation**](TssV2TransactionsGet200ResponsePointOfSaleInformation.md) | | [optional]
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Properties
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
|
-
**customerId** | **String** | Unique identifier for the
|
|
6
|
+
**customerId** | **String** | Unique identifier for the customer's card and billing information. When you use Payment Tokenization or Recurring Billing and you include this value in your request, many of the fields that are normally required for an authorization or credit become optional. **NOTE** When you use Payment Tokenization or Recurring Billing, the value for the Customer ID is actually the Cybersource payment token for a customer. This token stores information such as the consumer’s card number so it can be applied towards bill payments, recurring payments, or one-time payments. By using this token in a payment API request, the merchant doesn't need to pass in data such as the card number or expiration date in the request itself. For details, see the `subscription_id` field description in [Credit Card Services Using the SCMP API.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) | [optional]
|
|
7
7
|
**id** | **String** | Unique identifier for the Customer token that was created as part of a bundled TOKEN_CREATE action. | [optional]
|
|
8
8
|
|
|
9
9
|
|
|
@@ -4,6 +4,6 @@
|
|
|
4
4
|
Name | Type | Description | Notes
|
|
5
5
|
------------ | ------------- | ------------- | -------------
|
|
6
6
|
**authType** | **String** | Authorization type. Possible values: - `AUTOCAPTURE`: automatic capture. - `STANDARDCAPTURE`: standard capture. - `VERBAL`: forced capture. Include it in the payment request for a forced capture. Include it in the capture request for a verbal payment. #### Asia, Middle East, and Africa Gateway; Cielo; Comercio Latino; and CyberSource Latin American Processing Set this field to `AUTOCAPTURE` and include it in a bundled request to indicate that you are requesting an automatic capture. If your account is configured to enable automatic captures, set this field to `STANDARDCAPTURE` and include it in a standard authorization or bundled request to indicate that you are overriding an automatic capture. For more information, see the `auth_type` field description in [Credit Card Services Using the SCMP API Guide.](https://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html/) #### Forced Capture Set this field to `VERBAL` and include it in the authorization request to indicate that you are performing a forced capture; therefore, you receive the authorization code outside the CyberSource system. #### Verbal Authorization Set this field to `VERBAL` and include it in the capture request to indicate that the request is for a verbal authorization. For more information, see \"Verbal Authorizations\" in [Credit Card Services Using the SCMP API](http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_SCMP_API/html). | [optional]
|
|
7
|
-
**initiator** | [**
|
|
7
|
+
**initiator** | [**TssV2TransactionsGet200ResponseProcessingInformationAuthorizationOptionsInitiator**](TssV2TransactionsGet200ResponseProcessingInformationAuthorizationOptionsInitiator.md) | | [optional]
|
|
8
8
|
|
|
9
9
|
|