citypay_api_client 1.0.2 → 1.1.1

data/lib/citypay_api_client/api/operational_api.rb

@@ -1,147 +0,0 @@
-=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 <aside class=\"notice\">   Before we begin a reminder that 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 including: </aside>  * 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. 
-
-Contact: support@citypay.com
-Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 5.0.0-SNAPSHOT
-
-=end
-
-require 'cgi'
-
-module CityPayApiClient
-  class OperationalApi
-    attr_accessor :api_client
-
-    def initialize(api_client = ApiClient.default)
-      @api_client = api_client
-    end
-    # List Merchants Request
-    # An operational request to list current merchants for a client.  ### Sorting  Sorting can be performed by include a query parameter i.e. `/merchants/?sort=merchantid`  Fields that can be sorted are `merchantid` or `name`. 
-    # @param clientid [String] The client id to return merchants for, specifying \&quot;default\&quot; will use the value in your api key.
-    # @param [Hash] opts the optional parameters
-    # @return [ListMerchantsResponse]
-    def list_merchants_request(clientid, opts = {})
-      data, _status_code, _headers = list_merchants_request_with_http_info(clientid, opts)
-      data
-    end
-
-    # List Merchants Request
-    # An operational request to list current merchants for a client.  ### Sorting  Sorting can be performed by include a query parameter i.e. &#x60;/merchants/?sort&#x3D;merchantid&#x60;  Fields that can be sorted are &#x60;merchantid&#x60; or &#x60;name&#x60;. 
-    # @param clientid [String] The client id to return merchants for, specifying \&quot;default\&quot; will use the value in your api key.
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(ListMerchantsResponse, Integer, Hash)>] ListMerchantsResponse data, response status code and response headers
-    def list_merchants_request_with_http_info(clientid, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: OperationalApi.list_merchants_request ...'
-      end
-      # verify the required parameter 'clientid' is set
-      if @api_client.config.client_side_validation && clientid.nil?
-        fail ArgumentError, "Missing the required parameter 'clientid' when calling OperationalApi.list_merchants_request"
-      end
-      # resource path
-      local_var_path = '/merchants/{clientid}'.sub('{' + 'clientid' + '}', CGI.escape(clientid.to_s))
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] 
-
-      # return_type
-      return_type = opts[:return_type] || 'ListMerchantsResponse' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:GET, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: OperationalApi#list_merchants_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    end
-
-    # Ping Request
-    # A ping request which performs a connection and authentication test to the CityPay API server. The request will return a standard Acknowledgement with a response code `044` to signify a successful ping.  The ping call is useful to confirm that you will be able to access  the API from behind any firewalls and that the permission model is granting access from your source. 
-    # @param ping [Ping] 
-    # @param [Hash] opts the optional parameters
-    # @return [Acknowledgement]
-    def ping_request(ping, opts = {})
-      data, _status_code, _headers = ping_request_with_http_info(ping, opts)
-      data
-    end
-
-    # Ping Request
-    # A ping request which performs a connection and authentication test to the CityPay API server. The request will return a standard Acknowledgement with a response code &#x60;044&#x60; to signify a successful ping.  The ping call is useful to confirm that you will be able to access  the API from behind any firewalls and that the permission model is granting access from your source. 
-    # @param ping [Ping] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
-    def ping_request_with_http_info(ping, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: OperationalApi.ping_request ...'
-      end
-      # verify the required parameter 'ping' is set
-      if @api_client.config.client_side_validation && ping.nil?
-        fail ArgumentError, "Missing the required parameter 'ping' when calling OperationalApi.ping_request"
-      end
-      # resource path
-      local_var_path = '/ping'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(ping) 
-
-      # return_type
-      return_type = opts[:return_type] || 'Acknowledgement' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: OperationalApi#ping_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    end
-  end
-end

data/lib/citypay_api_client/api/payment_processing_api.rb

@@ -1,405 +0,0 @@
-=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 <aside class=\"notice\">   Before we begin a reminder that 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 including: </aside>  * 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. 
-
-Contact: support@citypay.com
-Generated by: https://openapi-generator.tech
-OpenAPI Generator version: 5.0.0-SNAPSHOT
-
-=end
-
-require 'cgi'
-
-module CityPayApiClient
-  class PaymentProcessingApi
-    attr_accessor :api_client
-
-    def initialize(api_client = ApiClient.default)
-      @api_client = api_client
-    end
-    # 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 3DSv1 and 3DSv2 transactions, the API contains a fully accredited in built mechanism to handle authentication.  The gateway has been accredited extensively with both Acquirers and Card Schemes and simplifies the nature of these calls into a simple structure for authentication, preventing integrators from performing lengthy and a costly accreditation 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) as evidence of authorisation.   #### 3DSv1  ```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.  ```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.    #### 3DSv2  ```json {    \"RequestChallenged\": {     \"acsurl\": \"https://bank.com/3DS/ACS\",     \"creq\": \"SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\"   }                } ```  ```xml <RequestChallenged>  <acsurl>https://bank.com/3DS/ACS</acsurl>  <creq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</creq> </RequestChallenged> ```  All merchants in the EEC will require to migrate their E-commerce transactions to a secure customer authentication  model (SCA) throughout 2020. This has been adopted by the payment's industry as a progressive move alongside the European  Unions payments service directive.  CityPay support 3DSv2 for Verified by Visa, MasterCard Identity Check and American Express SafeKey 2.0 and will be rolling out acquirers on the new platform from Q2 2020. The new enhancement to 3DSv2 will allow for CityPay to seamlessly authenticate transactions in a \"frictionless\" flowed method which will authenticate low risk transactions with minimal impact to a  standard authorisation flow. Our API simply performs this on behalf of the merchant and cardholder. For these transactions you will not be required to change anything.  However, should a transaction be \"challenged\" 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) by posting the [creq](#creq) 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`.  Our servers however will await confirmation that the authorisation should continue and on receipt of a [cres](#cres) value, the flow will 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 back response codes illustrating this.   To forward the user to the ACS, we recommend a 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}}\" />         </form>     </body> </html> ```  We are currently working on an integration test suite for 3DSv2 which will mock the ACS challenge process. 
-    # @param auth_request [AuthRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Decision]
-    def authorisation_request(auth_request, opts = {})
-      data, _status_code, _headers = authorisation_request_with_http_info(auth_request, opts)
-      data
-    end
-
-    # 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 3DSv1 and 3DSv2 transactions, the API contains a fully accredited in built mechanism to handle authentication.  The gateway has been accredited extensively with both Acquirers and Card Schemes and simplifies the nature of these calls into a simple structure for authentication, preventing integrators from performing lengthy and a costly accreditation 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) as evidence of authorisation.   #### 3DSv1  &#x60;&#x60;&#x60;json {    \&quot;AuthenticationRequired\&quot;: {     \&quot;acsurl\&quot;: \&quot;https://bank.com/3DS/ACS\&quot;,     \&quot;pareq\&quot;: \&quot;SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\&quot;,     \&quot;md\&quot;: \&quot;WQgZXZlcnl0aGluZyBiZW\&quot;   }                } &#x60;&#x60;&#x60;  &#x60;&#x60;&#x60;xml &lt;AuthenticationRequired&gt;  &lt;acsurl&gt;https://bank.com/3DS/ACS&lt;/acsurl&gt;  &lt;pareq&gt;SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...&lt;/pareq&gt;  &lt;md&gt;WQgZXZlcnl0aGluZyBiZW&lt;/md&gt; &lt;/AuthenticationRequired&gt; &#x60;&#x60;&#x60;  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&#39;s browser to an authentication server (ACS)  to gain the user&#39;s authentication. Once complete, the ACS will produce a HTTP &#x60;POST&#x60; call back to the URL supplied in   the authentication request as &#x60;merchant_termurl&#x60;. 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&#39;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.  &#x60;&#x60;&#x60;html &lt;html lang&#x3D;\&quot;en\&quot;&gt;  &lt;head&gt;         &lt;title&gt;Forward to ACS&lt;/title&gt;   &lt;script type&#x3D;\&quot;text/javascript\&quot;&gt;         function onLoadEvent() {              document.acs.submit();          }         &lt;/script&gt;         &lt;noscript&gt;You will require JavaScript to be enabled to complete this transaction&lt;/noscript&gt;     &lt;/head&gt;     &lt;body onload&#x3D;\&quot;onLoadEvent();\&quot;&gt;         &lt;form name&#x3D;\&quot;acs\&quot; action&#x3D;\&quot;{{ACSURL from Response}}\&quot; method&#x3D;\&quot;POST\&quot;&gt;             &lt;input type&#x3D;\&quot;hidden\&quot; name&#x3D;\&quot;PaReq\&quot; value&#x3D;\&quot;{{PaReq Packet from Response}}\&quot; /&gt;             &lt;input type&#x3D;\&quot;hidden\&quot; name&#x3D;\&quot;TermUrl\&quot; value&#x3D;\&quot;{{Your Controller}}\&quot; /&gt;             &lt;input type&#x3D;\&quot;hidden\&quot; name&#x3D;\&quot;MD\&quot; value&#x3D;\&quot;{{MD From Response}}\&quot; /&gt;         &lt;/form&gt;     &lt;/body&gt; &lt;/html&gt; &#x60;&#x60;&#x60;  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.    #### 3DSv2  &#x60;&#x60;&#x60;json {    \&quot;RequestChallenged\&quot;: {     \&quot;acsurl\&quot;: \&quot;https://bank.com/3DS/ACS\&quot;,     \&quot;creq\&quot;: \&quot;SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\&quot;   }                } &#x60;&#x60;&#x60;  &#x60;&#x60;&#x60;xml &lt;RequestChallenged&gt;  &lt;acsurl&gt;https://bank.com/3DS/ACS&lt;/acsurl&gt;  &lt;creq&gt;SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...&lt;/creq&gt; &lt;/RequestChallenged&gt; &#x60;&#x60;&#x60;  All merchants in the EEC will require to migrate their E-commerce transactions to a secure customer authentication  model (SCA) throughout 2020. This has been adopted by the payment&#39;s industry as a progressive move alongside the European  Unions payments service directive.  CityPay support 3DSv2 for Verified by Visa, MasterCard Identity Check and American Express SafeKey 2.0 and will be rolling out acquirers on the new platform from Q2 2020. The new enhancement to 3DSv2 will allow for CityPay to seamlessly authenticate transactions in a \&quot;frictionless\&quot; flowed method which will authenticate low risk transactions with minimal impact to a  standard authorisation flow. Our API simply performs this on behalf of the merchant and cardholder. For these transactions you will not be required to change anything.  However, should a transaction be \&quot;challenged\&quot; the API will return a [request challenge](#requestchallenged) which will  require your integration to forward the cardholder&#39;s browser to the given [ACS url](#acsurl) by posting the [creq](#creq) value. Once complete, the ACS will have already been in touch with our servers by sending us a result of the authentication known as &#x60;RReq&#x60;.  Our servers however will await confirmation that the authorisation should continue and on receipt of a [cres](#cres) value, the flow will 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 back response codes illustrating this.   To forward the user to the ACS, we recommend a simple auto submit HTML form.  &#x60;&#x60;&#x60;html &lt;html lang&#x3D;\&quot;en\&quot;&gt;  &lt;head&gt;         &lt;title&gt;Forward to ACS&lt;/title&gt;   &lt;script type&#x3D;\&quot;text/javascript\&quot;&gt;         function onLoadEvent() {              document.acs.submit();          }         &lt;/script&gt;         &lt;noscript&gt;You will require JavaScript to be enabled to complete this transaction&lt;/noscript&gt;     &lt;/head&gt;     &lt;body onload&#x3D;\&quot;onLoadEvent();\&quot;&gt;         &lt;form name&#x3D;\&quot;acs\&quot; action&#x3D;\&quot;{{ACSURL from Response}}\&quot; method&#x3D;\&quot;POST\&quot;&gt;             &lt;input type&#x3D;\&quot;hidden\&quot; name&#x3D;\&quot;creq\&quot; value&#x3D;\&quot;{{CReq Packet from Response}}\&quot; /&gt;         &lt;/form&gt;     &lt;/body&gt; &lt;/html&gt; &#x60;&#x60;&#x60;  We are currently working on an integration test suite for 3DSv2 which will mock the ACS challenge process. 
-    # @param auth_request [AuthRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(Decision, Integer, Hash)>] Decision data, response status code and response headers
-    def authorisation_request_with_http_info(auth_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PaymentProcessingApi.authorisation_request ...'
-      end
-      # verify the required parameter 'auth_request' is set
-      if @api_client.config.client_side_validation && auth_request.nil?
-        fail ArgumentError, "Missing the required parameter 'auth_request' when calling PaymentProcessingApi.authorisation_request"
-      end
-      # resource path
-      local_var_path = '/authorise'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(auth_request) 
-
-      # return_type
-      return_type = opts[:return_type] || 'Decision' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: PaymentProcessingApi#authorisation_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    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. 
-    # @param c_res_auth_request [CResAuthRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [AuthResponse]
-    def c_res_request(c_res_auth_request, opts = {})
-      data, _status_code, _headers = c_res_request_with_http_info(c_res_auth_request, opts)
-      data
-    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 &#x60;RReq&#x60; 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. 
-    # @param c_res_auth_request [CResAuthRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(AuthResponse, Integer, Hash)>] AuthResponse data, response status code and response headers
-    def c_res_request_with_http_info(c_res_auth_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PaymentProcessingApi.c_res_request ...'
-      end
-      # verify the required parameter 'c_res_auth_request' is set
-      if @api_client.config.client_side_validation && c_res_auth_request.nil?
-        fail ArgumentError, "Missing the required parameter 'c_res_auth_request' when calling PaymentProcessingApi.c_res_request"
-      end
-      # resource path
-      local_var_path = '/cres'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(c_res_auth_request) 
-
-      # return_type
-      return_type = opts[:return_type] || 'AuthResponse' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: PaymentProcessingApi#c_res_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    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. 
-    # @param capture_request [CaptureRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Acknowledgement]
-    def capture_request(capture_request, opts = {})
-      data, _status_code, _headers = capture_request_with_http_info(capture_request, opts)
-      data
-    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 [&#x60;Acknowledgement&#x60;](#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. 
-    # @param capture_request [CaptureRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
-    def capture_request_with_http_info(capture_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PaymentProcessingApi.capture_request ...'
-      end
-      # verify the required parameter 'capture_request' is set
-      if @api_client.config.client_side_validation && capture_request.nil?
-        fail ArgumentError, "Missing the required parameter 'capture_request' when calling PaymentProcessingApi.capture_request"
-      end
-      # resource path
-      local_var_path = '/capture'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(capture_request) 
-
-      # return_type
-      return_type = opts[:return_type] || 'Acknowledgement' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: PaymentProcessingApi#capture_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    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. 
-    # @param pa_res_auth_request [PaResAuthRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [AuthResponse]
-    def pa_res_request(pa_res_auth_request, opts = {})
-      data, _status_code, _headers = pa_res_request_with_http_info(pa_res_auth_request, opts)
-      data
-    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. 
-    # @param pa_res_auth_request [PaResAuthRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(AuthResponse, Integer, Hash)>] AuthResponse data, response status code and response headers
-    def pa_res_request_with_http_info(pa_res_auth_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PaymentProcessingApi.pa_res_request ...'
-      end
-      # verify the required parameter 'pa_res_auth_request' is set
-      if @api_client.config.client_side_validation && pa_res_auth_request.nil?
-        fail ArgumentError, "Missing the required parameter 'pa_res_auth_request' when calling PaymentProcessingApi.pa_res_request"
-      end
-      # resource path
-      local_var_path = '/pares'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(pa_res_auth_request) 
-
-      # return_type
-      return_type = opts[:return_type] || 'AuthResponse' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: PaymentProcessingApi#pa_res_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    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. 
-    # @param retrieve_request [RetrieveRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [AuthReferences]
-    def retrieval_request(retrieve_request, opts = {})
-      data, _status_code, _headers = retrieval_request_with_http_info(retrieve_request, opts)
-      data
-    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. 
-    # @param retrieve_request [RetrieveRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(AuthReferences, Integer, Hash)>] AuthReferences data, response status code and response headers
-    def retrieval_request_with_http_info(retrieve_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PaymentProcessingApi.retrieval_request ...'
-      end
-      # verify the required parameter 'retrieve_request' is set
-      if @api_client.config.client_side_validation && retrieve_request.nil?
-        fail ArgumentError, "Missing the required parameter 'retrieve_request' when calling PaymentProcessingApi.retrieval_request"
-      end
-      # resource path
-      local_var_path = '/retrieve'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(retrieve_request) 
-
-      # return_type
-      return_type = opts[:return_type] || 'AuthReferences' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: PaymentProcessingApi#retrieval_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    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. 
-    # @param void_request [VoidRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Acknowledgement]
-    def void_request(void_request, opts = {})
-      data, _status_code, _headers = void_request_with_http_info(void_request, opts)
-      data
-    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 [&#x60;Acknowledgement&#x60;](#acknowledgement) will be returned, outlining the result of the transaction. 
-    # @param void_request [VoidRequest] 
-    # @param [Hash] opts the optional parameters
-    # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
-    def void_request_with_http_info(void_request, opts = {})
-      if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: PaymentProcessingApi.void_request ...'
-      end
-      # verify the required parameter 'void_request' is set
-      if @api_client.config.client_side_validation && void_request.nil?
-        fail ArgumentError, "Missing the required parameter 'void_request' when calling PaymentProcessingApi.void_request"
-      end
-      # resource path
-      local_var_path = '/void'
-
-      # query parameters
-      query_params = opts[:query_params] || {}
-
-      # header parameters
-      header_params = opts[:header_params] || {}
-      # HTTP header 'Accept' (if needed)
-      header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
-      # HTTP header 'Content-Type'
-      header_params['Content-Type'] = @api_client.select_header_content_type(['application/json', 'text/xml'])
-
-      # form parameters
-      form_params = opts[:form_params] || {}
-
-      # http body (model)
-      post_body = opts[:body] || @api_client.object_to_http_body(void_request) 
-
-      # return_type
-      return_type = opts[:return_type] || 'Acknowledgement' 
-
-      # auth_names
-      auth_names = opts[:auth_names] || ['cp-api-key']
-
-      new_options = opts.merge(
-        :header_params => header_params,
-        :query_params => query_params,
-        :form_params => form_params,
-        :body => post_body,
-        :auth_names => auth_names,
-        :return_type => return_type
-      )
-
-      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
-      if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: PaymentProcessingApi#void_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
-      end
-      return data, status_code, headers
-    end
-  end
-end

data/lib/citypay_api_client/test.rb

@@ -1,20 +0,0 @@
-
-require 'citypay_api_client'
-
-# Setup authorization
-CityPayApiClient.configure do |config|
-  config.api_key['cp-api-key'] = CityPayApiClient::ApiKey.new(client_id: "PC874200", licence_key: "MT8NIRSTN9BHGJI8").generate
-  config.debugging = true
-end
-
-
-
-begin
-  card_holder_instance = CityPayApiClient::CardHolderAccountApi.new
-  resp = card_holder_instance.account_retrieve_request("b8219879-28fb-4be4-bcb9-6966c8da6559")
-  p resp
-  p resp.account_id
-  p resp.date_created
-rescue CityPayApiClient::ApiError => e
-  puts "Exception when calling CardHolderAccountApi->account_card_delete_request: #{e}"
-end