citypay_api_client 1.1.1 → 1.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3018934533b8ffad25c118e803c368d46897f6b2a580e0c35c001d7e606ff4f0
-  data.tar.gz: 6ff21eeebb1ea06d1dfd7be47fb416148b2761fe9e95246dc34178092427c070
+  metadata.gz: ffc51d5a014c59fc14c213cd2f0340323c31e8094fc8602fc27e357675e5fe0d
+  data.tar.gz: 4584d27c08da5b4aa0742ba6177dcbaa0ff1e6822481461056aa721be5b12de0
 SHA512:
-  metadata.gz: da644228d47e92255fd06d90c45f8107d2d65ae2d224d51df0e6bb45885a4b7b9de78ed35f5725a7bf66c042a85b629f87726c59d9d10c078d0aa8df49fdd90d
-  data.tar.gz: d7e533a08e6899c9dcb1c6dc53e8e3a43d11b63a64a69a894a1bf36ba8fa9c129f43e79129eb0be056335691a4a0da4a821d7723fd2ac5d42da00b177d13293a
+  metadata.gz: 8d9330bc04c09a6ab2b5346db177aa58a13ec7357841fa718c4ad4df9371bf51aa730d6d064ae497e8a1e75268b3fab16bf979334589e1549ec3fcfbce8ffb4f
+  data.tar.gz: 3c9b157bd6def911f761a3964abe6ff459ab297451c9e120e3ad40ae28d519bf48af0b98a05dc92199127afcabc81e0a8ed22d6842b5718a8a360359789d557a

data/README.md

@@ -1,22 +1,22 @@
 # CityPay API Client for Ruby
 
 CityPayApiClient - the Ruby gem for the CityPay Payment API
-[![Build Status](https://api.travis-ci.com/citypay/citypay-api-client-ruby.svg?branch=master)](https://app.travis-ci.com/github/citypay/citypay-api-client-ruby)
+[![Ruby RSpec Tests](https://github.com/citypay/citypay-api-client-ruby/actions/workflows/build.yml/badge.svg)](https://github.com/citypay/citypay-api-client-ruby/actions/workflows/build.yml)
 
 
-This CityPay API is a HTTP RESTful payment API used for direct server to server transactional processing. It
+This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It
 provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing,
 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and
-Completion processing. The API is also capable of tokinsed payments using Card Holder Accounts.
+Completion processing. The API is also capable of tokenized payments using cardholder Accounts.
 
 ## Compliance and Security
 Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by 
 Visa and MasterCard and the PCI Security Standards Council. These include
 
-* Data must be collected using TLS version 1.2 using [strong cryptography](#enabled-tls-ciphers). We will not accept calls to our API at
+* Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at
   lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments
   as part of our compliance program.
-* The application must not store sensitive card holder data (CHD) such as the card security code (CSC) or
+* The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or
   primary access number (PAN)
 * The application must not display the full card number on receipts, it is recommended to mask the PAN
   and show the last 4 digits. The API will return this for you for ease of receipt creation
@@ -31,10 +31,10 @@ Visa and MasterCard and the PCI Security Standards Council. These include
 
 This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
 
-- API version: 6.4.18
-- Package version: 1.1.1
+- API version: 6.6.23
+- Package version: 1.1.2
 - Build package: org.openapitools.codegen.languages.RubyClientCodegen
-For more information, please visit [https://citypay.com/customer-centre/technical-support.html](https://citypay.com/customer-centre/technical-support.html)
+For more information, please visit [https://www.citypay.com/contacts/](https://www.citypay.com/contacts/)
 
 ## Installation
 
@@ -49,16 +49,16 @@ gem build citypay_api_client.gemspec
 Then either install the gem locally:
 
 ```shell
-gem install ./citypay_api_client-1.1.1.gem
+gem install ./citypay_api_client-1.1.2.gem
 ```
 
-(for development, run `gem install --dev ./citypay_api_client-1.1.1.gem` to install the development dependencies)
+(for development, run `gem install --dev ./citypay_api_client-1.1.2.gem` to install the development dependencies)
 
 or publish the gem to a gem hosting service, e.g. [RubyGems](https://rubygems.org/).
 
 Finally add this to the Gemfile:
 
-    gem 'citypay_api_client', '~> 1.1.1'
+    gem 'citypay_api_client', '~> 1.1.2'
 
 ### Install from Git
 
@@ -88,7 +88,7 @@ CityPayApiClient.configure do |config|
 end
 
 api_instance = CityPayApiClient::AuthorisationAndPaymentApi.new
-auth_request = CityPayApiClient::AuthRequest.new({amount: 3600, cardnumber: '4000 0000 0000 0002', expmonth: 9, expyear: 2025, identifier: '95b857a1-5955-4b86-963c-5a6dbfc4fb95', merchantid: 11223344}) # AuthRequest | 
+auth_request = CityPayApiClient::AuthRequest.new({amount: 3600, cardnumber: '4000 0000 0000 0002', expmonth: 9, expyear: 2027, identifier: '95b857a1-5955-4b86-963c-5a6dbfc4fb95', merchantid: 11223344}) # AuthRequest | 
 
 begin
   #Authorisation
@@ -115,7 +115,7 @@ Class | Method | HTTP request | Description
 *CityPayApiClient::AuthorisationAndPaymentApi* | [**retrieval_request**](docs/AuthorisationAndPaymentApi.md#retrieval_request) | **POST** /v6/retrieve | Retrieval
 *CityPayApiClient::AuthorisationAndPaymentApi* | [**void_request**](docs/AuthorisationAndPaymentApi.md#void_request) | **POST** /v6/void | Void
 *CityPayApiClient::BatchProcessingApi* | [**batch_process_request**](docs/BatchProcessingApi.md#batch_process_request) | **POST** /v6/batch/process | Batch Process Request
-*CityPayApiClient::BatchProcessingApi* | [**batch_report_request**](docs/BatchProcessingApi.md#batch_report_request) | **POST** /v6/batch/retrieve | BatchReportRequest
+*CityPayApiClient::BatchProcessingApi* | [**batch_retrieve_request**](docs/BatchProcessingApi.md#batch_retrieve_request) | **POST** /v6/batch/retrieve | BatchReportRequest
 *CityPayApiClient::BatchProcessingApi* | [**check_batch_status_request**](docs/BatchProcessingApi.md#check_batch_status_request) | **POST** /v6/batch/status | CheckBatchStatus
 *CityPayApiClient::CardHolderAccountApi* | [**account_card_delete_request**](docs/CardHolderAccountApi.md#account_card_delete_request) | **DELETE** /v6/account/{accountid}/card/{cardId} | Card Deletion
 *CityPayApiClient::CardHolderAccountApi* | [**account_card_register_request**](docs/CardHolderAccountApi.md#account_card_register_request) | **POST** /v6/account/{accountid}/register | Card Registration
@@ -138,13 +138,13 @@ Class | Method | HTTP request | Description
 *CityPayApiClient::OperationalFunctionsApi* | [**list_merchants_request**](docs/OperationalFunctionsApi.md#list_merchants_request) | **GET** /v6/merchants/{clientid} | List Merchants Request
 *CityPayApiClient::OperationalFunctionsApi* | [**ping_request**](docs/OperationalFunctionsApi.md#ping_request) | **POST** /v6/ping | Ping Request
 *CityPayApiClient::PaylinkApi* | [**token_adjustment_request**](docs/PaylinkApi.md#token_adjustment_request) | **POST** /paylink/{token}/adjustment | Paylink Token Adjustment
+*CityPayApiClient::PaylinkApi* | [**token_changes_request**](docs/PaylinkApi.md#token_changes_request) | **POST** /paylink/token/changes | Paylink Token Audit
 *CityPayApiClient::PaylinkApi* | [**token_close_request**](docs/PaylinkApi.md#token_close_request) | **PUT** /paylink/{token}/close | Close Paylink Token
 *CityPayApiClient::PaylinkApi* | [**token_create_bill_payment_request**](docs/PaylinkApi.md#token_create_bill_payment_request) | **POST** /paylink/bill-payment | Create Bill Payment Paylink Token
 *CityPayApiClient::PaylinkApi* | [**token_create_request**](docs/PaylinkApi.md#token_create_request) | **POST** /paylink/create | Create Paylink Token
 *CityPayApiClient::PaylinkApi* | [**token_purge_attachments_request**](docs/PaylinkApi.md#token_purge_attachments_request) | **PUT** /paylink/{token}/purge-attachments | Purges any attachments for a Paylink Token
 *CityPayApiClient::PaylinkApi* | [**token_reconciled_request**](docs/PaylinkApi.md#token_reconciled_request) | **PUT** /paylink/{token}/reconciled | Reconcile Paylink Token
 *CityPayApiClient::PaylinkApi* | [**token_reopen_request**](docs/PaylinkApi.md#token_reopen_request) | **PUT** /paylink/{token}/reopen | Reopen Paylink Token
-*CityPayApiClient::PaylinkApi* | [**token_status_changes_request**](docs/PaylinkApi.md#token_status_changes_request) | **POST** /paylink/token/changes | Paylink Token Audit
 *CityPayApiClient::PaylinkApi* | [**token_status_request**](docs/PaylinkApi.md#token_status_request) | **GET** /paylink/{token}/status | Paylink Token Status
 
 
@@ -229,6 +229,7 @@ Class | Method | HTTP request | Description
 ## Documentation for Authorization
 
 
+Authentication schemes defined for the API:
 ### cp-api-key
 
 

data/citypay_api_client.gemspec

@@ -3,11 +3,11 @@
 =begin
 #CityPay Payment API
 
-# This CityPay API is a HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokinsed payments using Card Holder Accounts.  ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by  Visa and MasterCard and the PCI Security Standards Council. These include  * Data must be collected using TLS version 1.2 using [strong cryptography](#enabled-tls-ciphers). We will not accept calls to our API at   lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments   as part of our compliance program. * The application must not store sensitive card holder data (CHD) such as the card security code (CSC) or   primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN   and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the   application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information   is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP   address. Our application firewalls analyse data that may be an attempt to break a large number of security common   security vulnerabilities. 
+# This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts.  ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by  Visa and MasterCard and the PCI Security Standards Council. These include  * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at   lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments   as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or   primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN   and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the   application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information   is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP   address. Our application firewalls analyse data that may be an attempt to break a large number of security common   security vulnerabilities. 
 
 Contact: support@citypay.com
 Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 6.2.1
+OpenAPI Generator version: 7.2.0
 
 =end
 
@@ -24,7 +24,8 @@ Gem::Specification.new do |s|
   s.summary     = "A ruby wrapper for the CityPay API"
   s.description = "CityPay API Client for Ruby"
   s.license     = "Unlicense"
-  s.required_ruby_version = ">= 2.4"
+  s.required_ruby_version = ">= 2.7"
+  s.metadata    = {}
 
   s.add_runtime_dependency 'typhoeus', '~> 1.0', '>= 1.0.1'
 

data/docs/AirlineAdvice.md

@@ -8,7 +8,7 @@
 | **conjunction_ticket_indicator** | **Boolean** | true if a conjunction ticket (with additional coupons) was issued for an itinerary with more than four segments. Defaults to false.  | [optional] |
 | **eticket_indicator** | **Boolean** | The Electronic Ticket Indicator, a code that indicates if an electronic ticket was issued.  Defaults to true. | [optional] |
 | **no_air_segments** | **Integer** | A value that indicates the number of air travel segments included on this ticket.  Valid entries include the numerals “0” through “4”. Required only if the transaction type is TKT or EXC.  | [optional] |
-| **number_in_party** | **Integer** | The number of people in the party. |  |
+| **number_in_party** | **Integer** | The number of people in the party. | [optional] |
 | **original_ticket_no** | **String** | Required if transaction type is EXC. | [optional] |
 | **passenger_name** | **String** | The name of the passenger when the traveller is not the card member that purchased the ticket. Required only if the transaction type is TKT or EXC. | [optional] |
 | **segment1** | [**AirlineSegment**](AirlineSegment.md) |  |  |

data/docs/AuthRequest.md

@@ -23,6 +23,7 @@
 | **merchantid** | **Integer** | Identifies the merchant account to perform processing for. |  |
 | **name_on_card** | **String** | The card holder name as appears on the card such as MR N E BODY. Required for some acquirers.  | [optional] |
 | **ship_to** | [**ContactDetails**](ContactDetails.md) |  | [optional] |
+| **tag** | **String** | A \"tag\" is a label that you can attach to a payment authorization. Tags can help you group transactions together based on certain criteria, like a work job or a ticket number. They can also assist in filtering transactions when you're generating reports.  Multiple Tags You can add more than one tag to a transaction by separating them with commas.  Limitations There is a maximum limit of 3 tags that can be added to a single transaction. Each tag can be no longer than 20 characters and alphanumeric with no spaces.  Example: Let's say you're a software company and you have different teams working on various projects. When a team makes a purchase or incurs an expense, they can tag the transaction with the project name, the team name, and the type of expense.  Project Name: Project_X Team Name: Team_A Type of Expense: Hardware So, the tag for a transaction might look like: Project_X,Team_A,Hardware  This way, when you're looking at your financial reports, you can easily filter transactions based on these tags to see how much each project or team is spending on different types of expenses.  | [optional] |
 | **threedsecure** | [**ThreeDSecure**](ThreeDSecure.md) |  | [optional] |
 | **trans_info** | **String** | Further information that can be added to the transaction will display in reporting. Can be used for flexible values such as operator id. | [optional] |
 | **trans_type** | **String** | The type of transaction being submitted. Normally this value is not required and your account manager may request that you set this field. | [optional] |
@@ -44,7 +45,7 @@ instance = CityPayApiClient::AuthRequest.new(
   duplicate_policy: null,
   event_management: null,
   expmonth: 9,
-  expyear: 2025,
+  expyear: 2027,
   external_mpi: null,
   identifier: 95b857a1-5955-4b86-963c-5a6dbfc4fb95,
   match_avsa: null,
@@ -52,6 +53,7 @@ instance = CityPayApiClient::AuthRequest.new(
   merchantid: 11223344,
   name_on_card: MR NE BODY,
   ship_to: null,
+  tag: null,
   threedsecure: null,
   trans_info: null,
   trans_type: null

data/docs/AuthResponse.md

@@ -27,7 +27,9 @@
 | **result** | **Integer** | An integer result that indicates the outcome of the transaction. The Code value below maps to the result value  <table> <tr> <th>Code</th> <th>Abbrev</th> <th>Description</th> </tr> <tr><td>0</td><td>Declined</td><td>Declined</td></tr> <tr><td>1</td><td>Accepted</td><td>Accepted</td></tr> <tr><td>2</td><td>Rejected</td><td>Rejected</td></tr> <tr><td>3</td><td>Not Attempted</td><td>Not Attempted</td></tr> <tr><td>4</td><td>Referred</td><td>Referred</td></tr> <tr><td>5</td><td>PinRetry</td><td>Perform PIN Retry</td></tr> <tr><td>6</td><td>ForSigVer</td><td>Force Signature Verification</td></tr> <tr><td>7</td><td>Hold</td><td>Hold</td></tr> <tr><td>8</td><td>SecErr</td><td>Security Error</td></tr> <tr><td>9</td><td>CallAcq</td><td>Call Acquirer</td></tr> <tr><td>10</td><td>DNH</td><td>Do Not Honour</td></tr> <tr><td>11</td><td>RtnCrd</td><td>Retain Card</td></tr> <tr><td>12</td><td>ExprdCrd</td><td>Expired Card</td></tr> <tr><td>13</td><td>InvldCrd</td><td>Invalid Card No</td></tr> <tr><td>14</td><td>PinExcd</td><td>Pin Tries Exceeded</td></tr> <tr><td>15</td><td>PinInvld</td><td>Pin Invalid</td></tr> <tr><td>16</td><td>AuthReq</td><td>Authentication Required</td></tr> <tr><td>17</td><td>AuthenFail</td><td>Authentication Failed</td></tr> <tr><td>18</td><td>Verified</td><td>Card Verified</td></tr> <tr><td>19</td><td>Cancelled</td><td>Cancelled</td></tr> <tr><td>20</td><td>Un</td><td>Unknown</td></tr> <tr><td>21</td><td>Challenged</td><td>Challenged</td></tr> <tr><td>22</td><td>Decoupled</td><td>Decoupled</td></tr> <tr><td>23</td><td>Denied</td><td>Permission Denied</td></tr> </table>  |  |
 | **result_code** | **String** | The result code as defined in the Response Codes Reference for example 000 is an accepted live transaction whilst 001 is an accepted test transaction. Result codes identify the source of success and failure.  Codes may start with an alpha character i.e. C001 indicating a type of error such as a card validation error.  |  |
 | **result_message** | **String** | The message regarding the result which provides further narrative to the result code.  |  |
-| **scheme** | **String** | A name of the card scheme of the transaction that processed the transaction such as Visa or MasterCard.  | [optional] |
+| **scheme** | **String** | The name of the card scheme of the transaction that processed the transaction such as Visa or MasterCard.  | [optional] |
+| **scheme_id** | **String** | The name of the card scheme of the transaction such as VI or MC.  | [optional] |
+| **scheme_logo** | **String** | A url containing a logo of the card scheme.  | [optional] |
 | **sha256** | **String** | A SHA256 digest value of the transaction used to validate the response data The digest is calculated by concatenating   * authcode   * amount   * response_code   * merchant_id   * trans_no   * identifier   * licence_key - which is not provided in the response.  | [optional] |
 | **trans_status** | **String** | Used to identify the status of a transaction. The status is used to track a transaction through its life cycle.  <table> <tr> <th>Id</th> <th>Description</th> </tr> <tr> <td>O</td> <td>Transaction is open for settlement</td> </tr> <tr> <td>A</td> <td>Transaction is assigned for settlement and can no longer be voided</td> </tr> <tr> <td>S</td> <td>Transaction has been settled</td> </tr> <tr> <td>D</td> <td>Transaction has been declined</td> </tr> <tr> <td>R</td> <td>Transaction has been rejected</td> </tr> <tr> <td>P</td> <td>Transaction has been authorised only and awaiting a capture. Used in pre-auth situations</td> </tr> <tr> <td>C</td> <td>Transaction has been cancelled</td> </tr> <tr> <td>E</td> <td>Transaction has expired</td> </tr> <tr> <td>I</td> <td>Transaction has been initialised but no action was able to be carried out</td> </tr> <tr> <td>H</td> <td>Transaction is awaiting authorisation</td> </tr> <tr> <td>.</td> <td>Transaction is on hold</td> </tr> <tr> <td>V</td> <td>Transaction has been verified</td> </tr> </table>  | [optional] |
 | **transno** | **Integer** | The resulting transaction number, ordered incrementally from 1 for every merchant_id. The value will default to less than 1 for transactions that do not have a transaction number issued.  | [optional] |
@@ -62,6 +64,8 @@ instance = CityPayApiClient::AuthResponse.new(
   result_code: 0,
   result_message: Accepted Transaction,
   scheme: Visa,
+  scheme_id: MC,
+  scheme_logo: https://cdn.citypay.com/img/cs/visa-logo.svg,
   sha256: null,
   trans_status: null,
   transno: 78416

data/docs/AuthorisationAndPaymentApi.md

@@ -20,7 +20,235 @@ All URIs are relative to *https://api.citypay.com*
 
 Authorisation
 
-An authorisation process performs a standard transaction authorisation based on the provided parameters of its request. The CityPay gateway will route your transaction via an Acquiring bank for subsequent authorisation to the appropriate card  schemes such as Visa or MasterCard.  The authorisation API should be used for server environments to process transactions on demand and in realtime.   The authorisation API can be used for multiple types of transactions including E-commerce, mail order, telephone order, customer present (keyed), continuous authority, pre-authorisation and others. CityPay will configure your account for  the appropriate coding and this will perform transparently by the gateway.   Data properties that are required, may depend on the environment you are conducting payment for. Our API aims to be  flexible enough to cater for these structures. Our integration team will aid you in providing the necessary data to   transact.      ## E-commerce workflows   For E-commerce transactions requiring 3DS, the API contains a fully accredited in built mechanism to handle authentication.  The Api and gateway has been accredited extensively with both Acquirers and Card Schemes to simplify the nature of these calls into a simple structure for authentication, preventing integrators from performing lengthy and a costly accreditations with Visa and MasterCard.  3D-secure has been around for a number of years and aims to shift the liability of a transaction away from a merchant back to the card holder. A *liability shift* determines whether a card holder can charge back a transaction as unknown. Effectively the process asks for a card holder to authenticate the transaction prior to authorisation producing a Cardholder  verification value (CAVV) and ecommerce indicator (ECI) as evidence of authorisation.  3DS version 1 has now been replaced by 3DS version 2 to provide secure customer authentication (SCA) in line with EU regulation. 3DSv2 is being phased out and any accounts using version 1 of the protocol is expected to be migrated by March 2022.   Any new integrations should only consider 3DSv2 flows.   ### 3DSv2  ```json {    \"RequestChallenged\": {     \"acsurl\": \"https://bank.com/3DS/ACS\",     \"creq\": \"SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\",     \"merchantid\": 12345,     \"transno\": 1,     \"threedserver_trans_id\": \"d652d8d2-d74a-4264-a051-a7862b10d5d6\"   }                } ```  ```xml <RequestChallenged>   <acsurl>https://bank.com/3DS/ACS</acsurl>   <creq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</creq>   <merchantid>12345</merchantid>   <transno>1</transno>   <threedserver_trans_id>d652d8d2-d74a-4264-a051-a7862b10d5d6</threedserver_trans_id> </RequestChallenged> ```  CityPay support 3DS version 2.1 for Verified by Visa, MasterCard Identity Check and American Express SafeKey 2.1. Version 2.2 is currently in development however this will be a seamless upgrade for all integrations.  #### 3-D Secure - None  ![3DSv2 Frctionless Flow](/images/3dsv2-no3d.png)  A basic flow may involve no 3-D secure processing. This could happen if there is no ability to perform authentication. An enrollment check may apply an \"attempted\" resolution to processing. In this instance a transaction may not meet any liability shift. A transaction may result in a decline due to this. We are also able to prevent from transactions being presented for authorisation if this occurs.   #### 3-D Secure - Frictionless  ![3DSv2 Frctionless Flow](/images/3dsv2-frictionless.png)  E-commerce transactions supporting 3DSv2 can benefit from seamlessly authenticated transactions which may perform a  \"frictionless\" flow. This method will authenticate low risk transactions with minimal impact to a  standard authorisation flow. Our API simply performs this on behalf of you the developer, the merchant and cardholder.  No redirection occurs and hence the flow is called frictionless and will appear as though a simple transaction  authorisation has occurred.  #### 3-D Secure - Challenge  ![3DSv2 Frctionless Flow](/images/3dsv2-challenge.png)  A transaction that is deemed as higher risk my be \"challenged\". In this instance, the API will return a [request challenge](#requestchallenged) which will require your integration to forward the cardholder's browser to the  given [ACS url](#acsurl). This should be performed by posting the [creq](#creq) value (the challenge request value).   Once complete, the ACS will have already been in touch with our servers by sending us a result of the authentication known as `RReq`.  To maintain session state, a parameter `threeDSSessionData` can be posted to the ACS url and will be returned alongside  the `CRes` value. This will ensure that any controller code will be able to isolate state between calls. This field is to be used by your own systems rather than ours and may be any value which can uniquely identify your cardholder's session. As an option, we do provide a `threedserver_trans_id` value in the `RequestChallenged` packet which can be used for the `threeDSSessionData` value as it is used to uniquely identify the 3D-Secure session.   A common method of maintaining state is to provide a session related query string value in the `merchant_termurl` value (also known as the `notificationUrl`). For example providing a url of `https://mystore.com/checkout?token=asny2348w4561..` could return the user directly back to their session with your environment.  Once you have received a `cres` post from the ACS authentication service, this should be POSTed to the [cres](#cres)  endpoint to perform full authorisation processing.   Please note that the CRes returned to us is purely a mechanism of acknowledging that transactions should be committed for authorisation. The ACS by this point will have sent us the verification value (CAVV) to perform a liability shift. The CRes value will be validated for receipt of the CAVV and subsequently may return response codes illustrating this.   To forward the user to the ACS, we recommend a simple auto submit HTML form.  > Simple auto submit HTML form  ```html <html lang=\"en\"> <head>         <title>Forward to ACS</title> <script type=\"text/javascript\">         function onLoadEvent() {              document.acs.submit();          }         </script>         <noscript>You will require JavaScript to be enabled to complete this transaction</noscript>     </head>     <body onload=\"onLoadEvent();\">         <form name=\"acs\" action=\"{{ACSURL from Response}}\" method=\"POST\">             <input type=\"hidden\" name=\"creq\" value=\"{{CReq Packet from Response}}\" />             <input type=\"hidden\" name=\"threeDSSessionData\" value=\"{{session-identifier}}\" />         </form>     </body> </html> ```  A full ACS test suite is available for 3DSv2 testing.          ### Testing 3DSv2 Integrations  The API provides a mock 3dsV2 handler which performs a number of scenarios based on the value of the CSC in the request.  | CSC Value | Behaviour | |-----------|-----------| | 731       | Frictionless processing - Not authenticated | | 732       | Frictionless processing - Account verification count not be performed |         | 733       | Frictionless processing - Verification Rejected |         | 741       | Frictionless processing - Attempts Processing |         | 750       | Frictionless processing - Authenticated  |         | 761       | Triggers an error message |   | Any       | Challenge Request |          #### 3DSv1  **Please note that 3DSv1 should now be considered as deprecated.**  ```json {    \"AuthenticationRequired\": {     \"acsurl\": \"https://bank.com/3DS/ACS\",     \"pareq\": \"SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\",     \"md\": \"WQgZXZlcnl0aGluZyBiZW\"   }                } ```  ```xml <AuthenticationRequired>  <acsurl>https://bank.com/3DS/ACS</acsurl>  <pareq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</pareq>  <md>WQgZXZlcnl0aGluZyBiZW</md> </AuthenticationRequired> ```  For E-commerce transactions requiring 3DSv1, the API contains a built in MPI which will be called to check whether the card is participating in 3DSv1 with Verified by Visa or MasterCard SecureCode. We only support Amex SafeKey with 3DSv2. Should the card be enrolled, a payer request (PAReq) value will be created and returned back as an [authentication required](#authenticationrequired) response object.  Your system will need to process this authentication packet and forward the user's browser to an authentication server (ACS) to gain the user's authentication. Once complete, the ACS will produce a HTTP `POST` call back to the URL supplied in the authentication request as `merchant_termurl`. This URL should behave as a controller and handle the post data from the ACS and on a forked server to server HTTP request, forward this data to the [pares authentication url](#pares) for subsequent authorisation processing. You may prefer to provide a processing page whilst this is being processed. Processing with our systems should be relatively quick and be between 500ms - 3000ms however it is desirable to let the user see that something is happening rather than a pending browser.  The main reason for ensuring that this controller is two fold:  1. We are never in control of the user's browser in a server API call 2. The controller is actioned on your site to ensure that any post actions from authorisation can be executed in real time  To forward the user to the ACS, we recommend a simple auto submit HTML form.  > Simple auto submit HTML form  ```html <html lang=\"en\"> <head>         <title>Forward to ACS</title> <script type=\"text/javascript\">         function onLoadEvent() {              document.acs.submit();          }         </script>         <noscript>You will require JavaScript to be enabled to complete this transaction</noscript>     </head>     <body onload=\"onLoadEvent();\">         <form name=\"acs\" action=\"{{ACSURL from Response}}\" method=\"POST\">             <input type=\"hidden\" name=\"PaReq\" value=\"{{PaReq Packet from Response}}\" />             <input type=\"hidden\" name=\"TermUrl\" value=\"{{Your Controller}}\" />             <input type=\"hidden\" name=\"MD\" value=\"{{MD From Response}}\" />         </form>     </body> </html> ```  Please note that 3DSv1 is being phased out due to changes to strong customer authentication mechanisms. 3DSv2 addresses this and will solidify the authorisation and confirmation process.  We provide a Test ACS for full 3DSv1 integration testing that simulates an ACS. 
+An authorisation process performs a standard transaction authorisation based on the provided parameters of its request.
+The CityPay gateway will route your transaction via an Acquiring bank for subsequent authorisation to the appropriate card 
+schemes such as Visa or MasterCard.
+
+The authorisation API should be used for server environments to process transactions on demand and in realtime. 
+
+The authorisation API can be used for multiple types of transactions including E-commerce, mail order, telephone order,
+customer present (keyed), continuous authority, pre-authorisation and others. CityPay will configure your account for 
+the appropriate coding and this will perform transparently by the gateway. 
+
+Data properties that are required, may depend on the environment you are conducting payment for. Our API aims to be
+ flexible enough to cater for these structures. Our integration team will aid you in providing the necessary data to 
+ transact. 
+
+```json
+{ 
+  "RequestChallenged": {
+    "acsurl": "https://bank.com/3DS/ACS",
+    "creq": "SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...",
+    "merchantid": 12345,
+    "transno": 1,
+    "threedserver_trans_id": "d652d8d2-d74a-4264-a051-a7862b10d5d6"
+  }               
+}
+```
+ 
+## E-commerce workflows
+ 
+For E-commerce transactions requiring 3DS, the API contains a fully accredited in built mechanism to handle authentication.
+
+The Api and gateway has been accredited extensively with both Acquirers and Card Schemes to simplify the nature of these calls
+into a simple structure for authentication, preventing integrators from performing lengthy and a costly accreditations with
+Visa and MasterCard.
+
+3D-secure has been around for a number of years and aims to shift the liability of a transaction away from a merchant back
+to the cardholder. A *liability shift* determines whether a card holder can charge back a transaction as unknown. Effectively
+the process asks for a card holder to authenticate the transaction prior to authorisation producing a Cardholder 
+verification value (CAVV) and ecommerce indicator (ECI) as evidence of authorisation.
+
+3DS version 1 has now been replaced by 3DS version 2 to provide secure customer authentication (SCA) in line with EU regulation.
+3DSv2 is being phased out and any accounts using version 1 of the protocol is expected to be migrated by March 2022. 
+
+Any new integrations should only consider 3DSv2 flows. 
+
+### 3DSv2
+
+```json
+{ 
+  "RequestChallenged": {
+    "acsurl": "https://bank.com/3DS/ACS",
+    "creq": "SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...",
+    "merchantid": 12345,
+    "transno": 1,
+    "threedserver_trans_id": "d652d8d2-d74a-4264-a051-a7862b10d5d6"
+  }               
+}
+```
+
+```xml
+<RequestChallenged>
+  <acsurl>https://bank.com/3DS/ACS</acsurl>
+  <creq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</creq>
+  <merchantid>12345</merchantid>
+  <transno>1</transno>
+  <threedserver_trans_id>d652d8d2-d74a-4264-a051-a7862b10d5d6</threedserver_trans_id>
+</RequestChallenged>
+```
+
+CityPay support 3DS version 2.1 for Verified by Visa, MasterCard Identity Check and American Express SafeKey 2.1. Version
+2.2 is currently in development however this will be a seamless upgrade for all integrations.
+
+#### 3-D Secure - None
+
+![3DSv2 Frctionless Flow](images/3dsv2-no3d.png)
+
+A basic flow may involve no 3-D secure processing. This could happen if there is no ability to perform authentication.
+An enrollment check may apply an "attempted" resolution to processing. In this instance a transaction may not meet any
+liability shift. A transaction may result in a decline due to this. We are also able to prevent from transactions being
+presented for authorisation if this occurs. 
+
+#### 3-D Secure - Frictionless
+
+![3DSv2 Frctionless Flow](images/3dsv2-frictionless.png)
+
+E-commerce transactions supporting 3DSv2 can benefit from seamlessly authenticated transactions which may perform a 
+"frictionless" flow. This method will authenticate low risk transactions with minimal impact to a 
+standard authorisation flow. Our API simply performs this on behalf of you the developer, the merchant and cardholder.
+
+No redirection occurs and hence the flow is called frictionless and will appear as though a simple transaction 
+authorisation has occurred.
+
+#### 3-D Secure - Challenge
+
+![3DSv2 Frctionless Flow](images/3dsv2-challenge.png)
+
+A transaction that is deemed as higher risk my be "challenged". In this instance, the API will return a
+[request challenge](#requestchallenged) which will require your integration to forward the cardholder's browser to the 
+given [ACS url](#acsurl). This should be performed by posting the [creq](#creq) value (the challenge request value). 
+
+Once complete, the ACS will have already been in touch with our servers by sending us a result of the authentication
+known as `RReq`.
+
+To maintain session state, a parameter `threeDSSessionData` can be posted to the ACS url and will be returned alongside 
+the `CRes` value. This will ensure that any controller code will be able to isolate state between calls. This field
+is to be used by your own systems rather than ours and may be any value which can uniquely identify your cardholder's
+session. As an option, we do provide a `threedserver_trans_id` value in the `RequestChallenged` packet which can be used
+for the `threeDSSessionData` value as it is used to uniquely identify the 3D-Secure session. 
+
+A common method of maintaining state is to provide a session related query string value in the `merchant_termurl` value
+(also known as the `notificationUrl`). For example providing a url of `https://mystore.com/checkout?token=asny2348w4561..`
+could return the user directly back to their session with your environment.
+
+Once you have received a `cres` post from the ACS authentication service, this should be POSTed to the [cres](#cres) 
+endpoint to perform full authorisation processing. 
+
+Please note that the CRes returned to us is purely a mechanism of acknowledging that transactions should be committed for
+authorisation. The ACS by this point will have sent us the verification value (CAVV) to perform a liability shift. The CRes
+value will be validated for receipt of the CAVV and subsequently may return response codes illustrating this. 
+
+To forward the user to the ACS, we recommend a simple auto submit HTML form.
+
+> Simple auto submit HTML form
+
+```html
+<html lang="en">
+	<head>
+        <title>Forward to ACS</title>
+		<script type="text/javascript">
+        function onLoadEvent() { 
+            document.acs.submit(); 
+        }
+        </script>
+        <noscript>You will require JavaScript to be enabled to complete this transaction</noscript>
+    </head>
+    <body onload="onLoadEvent();">
+        <form name="acs" action="{{ACSURL from Response}}" method="POST">
+            <input type="hidden" name="creq" value="{{CReq Packet from Response}}" />
+            <input type="hidden" name="threeDSSessionData" value="{{session-identifier}}" />
+        </form>
+    </body>
+</html>
+```
+
+A full ACS test suite is available for 3DSv2 testing.
+        
+### Testing 3DSv2 Integrations
+
+The API provides a mock 3dsV2 handler which performs a number of scenarios based on the value of the CSC in the request.
+
+| CSC Value | Behaviour |
+|-----------|-----------|
+| 731       | Frictionless processing - Not authenticated |
+| 732       | Frictionless processing - Account verification count not be performed |        
+| 733       | Frictionless processing - Verification Rejected |        
+| 741       | Frictionless processing - Attempts Processing |        
+| 750       | Frictionless processing - Authenticated  |        
+| 761       | Triggers an error message |  
+| Any       | Challenge Request |       
+
+
+#### 3DSv1
+
+**Please note that 3DSv1 should now be considered as deprecated.**
+
+```json
+{ 
+  "AuthenticationRequired": {
+    "acsurl": "https://bank.com/3DS/ACS",
+    "pareq": "SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...",
+    "md": "WQgZXZlcnl0aGluZyBiZW"
+  }               
+}
+```
+
+```xml
+<AuthenticationRequired>
+ <acsurl>https://bank.com/3DS/ACS</acsurl>
+ <pareq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</pareq>
+ <md>WQgZXZlcnl0aGluZyBiZW</md>
+</AuthenticationRequired>
+```
+
+For E-commerce transactions requiring 3DSv1, the API contains a built in MPI which will be called to check whether the
+card is participating in 3DSv1 with Verified by Visa or MasterCard SecureCode. We only support Amex SafeKey with 3DSv2. Should the card be enrolled, a payer
+request (PAReq) value will be created and returned back as an [authentication required](#authenticationrequired) response object.
+
+Your system will need to process this authentication packet and forward the user's browser to an authentication server (ACS)
+to gain the user's authentication. Once complete, the ACS will produce a HTTP `POST` call back to the URL supplied in
+the authentication request as `merchant_termurl`. This URL should behave as a controller and handle the post data from the
+ACS and on a forked server to server HTTP request, forward this data to the [pares authentication url](#pares) for
+subsequent authorisation processing. You may prefer to provide a processing page whilst this is being processed.
+Processing with our systems should be relatively quick and be between 500ms - 3000ms however it is desirable to let
+the user see that something is happening rather than a pending browser.
+
+The main reason for ensuring that this controller is two fold:
+
+1. We are never in control of the user's browser in a server API call
+2. The controller is actioned on your site to ensure that any post actions from authorisation can be executed in real time
+
+To forward the user to the ACS, we recommend a simple auto submit HTML form.
+
+> Simple auto submit HTML form
+
+```html
+<html lang="en">
+	<head>
+        <title>Forward to ACS</title>
+		<script type="text/javascript">
+        function onLoadEvent() { 
+            document.acs.submit(); 
+        }
+        </script>
+        <noscript>You will require JavaScript to be enabled to complete this transaction</noscript>
+    </head>
+    <body onload="onLoadEvent();">
+        <form name="acs" action="{{ACSURL from Response}}" method="POST">
+            <input type="hidden" name="PaReq" value="{{PaReq Packet from Response}}" />
+            <input type="hidden" name="TermUrl" value="{{Your Controller}}" />
+            <input type="hidden" name="MD" value="{{MD From Response}}" />
+        </form>
+    </body>
+</html>
+```
+
+Please note that 3DSv1 is being phased out due to changes to strong customer authentication mechanisms. 3DSv2 addresses
+this and will solidify the authorisation and confirmation process.
+
+We provide a Test ACS for full 3DSv1 integration testing that simulates an ACS.
+
 
 ### Examples
 
@@ -33,7 +261,7 @@ CityPayApiClient.configure do |config|
 end
 
 api_instance = CityPayApiClient::AuthorisationAndPaymentApi.new
-auth_request = CityPayApiClient::AuthRequest.new({amount: 3600, cardnumber: '4000 0000 0000 0002', expmonth: 9, expyear: 2025, identifier: '95b857a1-5955-4b86-963c-5a6dbfc4fb95', merchantid: 11223344}) # AuthRequest | 
+auth_request = CityPayApiClient::AuthRequest.new({amount: 3600, cardnumber: '4000 0000 0000 0002', expmonth: 9, expyear: 2027, identifier: '95b857a1-5955-4b86-963c-5a6dbfc4fb95', merchantid: 11223344}) # AuthRequest | 
 
 begin
   # Authorisation
@@ -88,7 +316,18 @@ end
 
 Bin Lookup
 
-A bin range lookup service can be used to check what a card is, as seen by the gateway. Each card number's  leading digits help to identify who  0. the card scheme is such as Visa, MasterCard or American Express  1. the issuer of the card, such as the bank 2. it's country of origin 3. it's currency of origin  Our gateway has 450 thousand possible bin ranges and uses a number of algorithms to determine the likelihood of the bin data. The request requires a bin value of between 6 and 12 digits. The more digits provided may ensure a more accurate result. 
+A bin range lookup service can be used to check what a card is, as seen by the gateway. Each card number's 
+leading digits help to identify who
+
+0. the card scheme is such as Visa, MasterCard or American Express 
+1. the issuer of the card, such as the bank
+2. it's country of origin
+3. it's currency of origin
+
+Our gateway has 450 thousand possible bin ranges and uses a number of algorithms to determine the likelihood of the bin
+data. The request requires a bin value of between 6 and 12 digits. The more digits provided may ensure a more accurate
+result.
+
 
 ### Examples
 
@@ -156,7 +395,14 @@ end
 
 CRes
 
-The CRes request performs authorisation processing once a challenge request has been completed with an Authentication Server (ACS). This challenge response contains confirmation that will allow the API systems to return an authorisation response based on the result. Our systems will  know out of band via an `RReq` call by the ACS to notify us if the liability shift has been issued.  Any call to the CRes operation will require a previous authorisation request and cannot be called  on its own without a previous [request challenge](#requestchallenged) being obtained. 
+The CRes request performs authorisation processing once a challenge request has been completed
+with an Authentication Server (ACS). This challenge response contains confirmation that will
+allow the API systems to return an authorisation response based on the result. Our systems will 
+know out of band via an `RReq` call by the ACS to notify us if the liability shift has been issued.
+
+Any call to the CRes operation will require a previous authorisation request and cannot be called 
+on its own without a previous [request challenge](#requestchallenged) being obtained.
+
 
 ### Examples
 
@@ -224,7 +470,24 @@ end
 
 Capture
 
-_The capture process only applies to transactions which have been pre-authorised only._   The capture process will ensure that a transaction will now settle. It is expected that a capture call will be provided within 3 days or a maximum of 7 days.  A capture request is provided to confirm that you wish the transaction to be settled. This request can contain a final amount for the transaction which is different to the original authorisation amount. This may be useful in a delayed system process such as waiting for stock to be ordered, confirmed, or services provided before the final cost is known.  When a transaction is completed, a new authorisation code may be created and a new confirmation can be sent online to the acquiring bank.  Once the transaction has been processed. A standard [`Acknowledgement`](#acknowledgement) will be returned, outlining the result of the transaction. On a successful completion process, the transaction will be available for the settlement and completed at the end of the day. 
+_The capture process only applies to transactions which have been pre-authorised only._ 
+
+The capture process will ensure
+that a transaction will now settle. It is expected that a capture call will be provided within 3 days or
+a maximum of 7 days.
+
+A capture request is provided to confirm that you wish the transaction to be settled. This request can
+contain a final amount for the transaction which is different to the original authorisation amount. This
+may be useful in a delayed system process such as waiting for stock to be ordered, confirmed, or services
+provided before the final cost is known.
+
+When a transaction is completed, a new authorisation code may be created and a new confirmation
+can be sent online to the acquiring bank.
+
+Once the transaction has been processed. A standard [`Acknowledgement`](#acknowledgement) will be returned,
+outlining the result of the transaction. On a successful completion process, the transaction will
+be available for the settlement and completed at the end of the day.
+
 
 ### Examples
 
@@ -292,7 +555,14 @@ end
 
 PaRes
 
-The Payer Authentication Response (PaRes) is an operation after the result of authentication   being performed. The request uses an encoded packet of authentication data to  notify us of the completion of the liability shift. Once this value has been unpacked and its signature is checked, our systems will proceed to authorisation processing.    Any call to the PaRes operation will require a previous authorisation request and cannot be called  on its own without a previous [authentication required](#authenticationrequired)  being obtained. 
+The Payer Authentication Response (PaRes) is an operation after the result of authentication 
+ being performed. The request uses an encoded packet of authentication data to 
+notify us of the completion of the liability shift. Once this value has been unpacked and its
+signature is checked, our systems will proceed to authorisation processing.  
+
+Any call to the PaRes operation will require a previous authorisation request and cannot be called 
+on its own without a previous [authentication required](#authenticationrequired)  being obtained.
+
 
 ### Examples
 
@@ -360,7 +630,10 @@ end
 
 Refund
 
-A refund request which allows for the refunding of a previous transaction up  and to the amount of the original sale. A refund will be performed against the  original card used to process the transaction. 
+A refund request which allows for the refunding of a previous transaction up 
+and to the amount of the original sale. A refund will be performed against the 
+original card used to process the transaction.
+
 
 ### Examples
 
@@ -428,7 +701,17 @@ end
 
 Retrieval
 
-A retrieval request which allows an integration to obtain the result of a transaction processed in the last 90 days. The request allows for retrieval based on the identifier or transaction  number.   The process may return multiple results in particular where a transaction was processed multiple times against the same identifier. This can happen if errors were first received. The API therefore returns up to the first 5 transactions in the latest date time order.  It is not intended for this operation to be a replacement for reporting and only allows for base transaction information to be returned. 
+A retrieval request which allows an integration to obtain the result of a transaction processed
+in the last 90 days. The request allows for retrieval based on the identifier or transaction 
+number. 
+
+The process may return multiple results in particular where a transaction was processed multiple
+times against the same identifier. This can happen if errors were first received. The API therefore
+returns up to the first 5 transactions in the latest date time order.
+
+It is not intended for this operation to be a replacement for reporting and only allows for base transaction
+information to be returned.
+
 
 ### Examples
 
@@ -496,7 +779,15 @@ end
 
 Void
 
-_The void process generally applies to transactions which have been pre-authorised only however voids can occur  on the same day if performed before batching and settlement._   The void process will ensure that a transaction will now settle. It is expected that a void call will be  provided on the same day before batching and settlement or within 3 days or within a maximum of 7 days.  Once the transaction has been processed as a void, an [`Acknowledgement`](#acknowledgement) will be returned, outlining the result of the transaction. 
+_The void process generally applies to transactions which have been pre-authorised only however voids can occur 
+on the same day if performed before batching and settlement._ 
+
+The void process will ensure that a transaction will now settle. It is expected that a void call will be 
+provided on the same day before batching and settlement or within 3 days or within a maximum of 7 days.
+
+Once the transaction has been processed as a void, an [`Acknowledgement`](#acknowledgement) will be returned,
+outlining the result of the transaction.
+
 
 ### Examples