Class: CityPayApiClient::AuthorisationAndPaymentApi

Inherits:
Object
  • Object
show all
Defined in:
lib/citypay_api_client/api/authorisation_and_payment_api__.rb

Instance Attribute Summary collapse

Instance Method Summary collapse

Constructor Details

#initialize(api_client = ApiClient.default) ⇒ AuthorisationAndPaymentApi

Returns a new instance of AuthorisationAndPaymentApi.



18
19
20
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 18

def initialize(api_client = ApiClient.default)
  @api_client = api_client
end

Instance Attribute Details

#api_client ⇒ Object

Returns the value of attribute api_client.



16
17
18
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 16

def api_client
  @api_client
end

Instance Method Details

#authorisation_request(auth_request, opts = {}) ⇒ Decision

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": "bank.com/3DS/ACS", "creq": "SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00…", "merchantid": 12345, "transno": 1, "threedserver_trans_id": "d652d8d2-d74a-4264-a051-a7862b10d5d6" } } “` “`xml <RequestChallenged> <acsurl>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 `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="from Response}" method="POST"> <input type="hidden" name="creq" value="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": "bank.com/3DS/ACS", "pareq": "SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00…", "md": "WQgZXZlcnl0aGluZyBiZW" } } “` “`xml <AuthenticationRequired> <acsurl>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="from Response}" method="POST"> <input type="hidden" name="PaReq" value="Packet from Response}" /> <input type="hidden" name="TermUrl" value="Controller}" /> <input type="hidden" name="MD" value="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.

Parameters:

  • auth_request (AuthRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



26
27
28
29
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 26

def authorisation_request(auth_request, opts = {})
  data, _status_code, _headers = authorisation_request_with_http_info(auth_request, opts)
  data
end

#authorisation_request_with_http_info(auth_request, opts = {}) ⇒ Array<(Decision, Integer, Hash)>

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 &#x60;&#x60;&#x60;json { &quot;RequestChallenged&quot;: { &quot;acsurl&quot;: &quot;bank.com/3DS/ACS&quot;, &quot;creq&quot;: &quot;SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00…&quot;, &quot;merchantid&quot;: 12345, &quot;transno&quot;: 1, &quot;threedserver_trans_id&quot;: &quot;d652d8d2-d74a-4264-a051-a7862b10d5d6&quot; } } &#x60;&#x60;&#x60; &#x60;&#x60;&#x60;xml &lt;RequestChallenged&gt; &lt;acsurl&gt;bank.com/3DS/ACS&lt;/acsurl&gt; &lt;creq&gt;SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00…&lt;/creq&gt; &lt;merchantid&gt;12345&lt;/merchantid&gt; &lt;transno&gt;1&lt;/transno&gt; &lt;threedserver_trans_id&gt;d652d8d2-d74a-4264-a051-a7862b10d5d6&lt;/threedserver_trans_id&gt; &lt;/RequestChallenged&gt; &#x60;&#x60;&#x60; 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 &quot;attempted&quot; 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 &quot;frictionless&quot; 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 &quot;challenged&quot;. In this instance, 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). 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 &#x60;RReq&#x60;. To maintain session state, a parameter &#x60;threeDSSessionData&#x60; can be posted to the ACS url and will be returned alongside the &#x60;CRes&#x60; 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&#39;s session. As an option, we do provide a &#x60;threedserver_trans_id&#x60; value in the &#x60;RequestChallenged&#x60; packet which can be used for the &#x60;threeDSSessionData&#x60; 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 &#x60;merchant_termurl&#x60; value (also known as the &#x60;notificationUrl&#x60;). For example providing a url of &#x60;mystore.com/checkout?token&#x3D;asny2348w4561..&#x60; could return the user directly back to their session with your environment. Once you have received a &#x60;cres&#x60; 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. &gt; 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;from Response}&quot; method&#x3D;&quot;POST&quot;&gt; &lt;input type&#x3D;&quot;hidden&quot; name&#x3D;&quot;creq&quot; value&#x3D;&quot;Packet from Response}&quot; /&gt; &lt;input type&#x3D;&quot;hidden&quot; name&#x3D;&quot;threeDSSessionData&quot; value&#x3D;&quot;{session-identifier}&quot; /&gt; &lt;/form&gt; &lt;/body&gt; &lt;/html&gt; &#x60;&#x60;&#x60; 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.** &#x60;&#x60;&#x60;json { &quot;AuthenticationRequired&quot;: { &quot;acsurl&quot;: &quot;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;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. &gt; 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;from Response}&quot; method&#x3D;&quot;POST&quot;&gt; &lt;input type&#x3D;&quot;hidden&quot; name&#x3D;&quot;PaReq&quot; value&#x3D;&quot;Packet from Response}&quot; /&gt; &lt;input type&#x3D;&quot;hidden&quot; name&#x3D;&quot;TermUrl&quot; value&#x3D;&quot;Controller}&quot; /&gt; &lt;input type&#x3D;&quot;hidden&quot; name&#x3D;&quot;MD&quot; value&#x3D;&quot;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.

Parameters:

  • auth_request (AuthRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(Decision, Integer, Hash)>) —

    Decision data, response status code and response headers



36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 36

def authorisation_request_with_http_info(auth_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.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 AuthorisationAndPaymentApi.authorisation_request"
  end
  # resource path
  local_var_path = '/v6/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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(auth_request)

  # return_type
  return_type = opts[:debug_return_type] || 'Decision'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.authorisation_request",
    :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: AuthorisationAndPaymentApi#authorisation_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#bin_range_lookup_request(bin_lookup, opts = {}) ⇒ Bin

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.

Parameters:

  • bin_lookup (BinLookup)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



94
95
96
97
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 94

def bin_range_lookup_request(bin_lookup, opts = {})
  data, _status_code, _headers = bin_range_lookup_request_with_http_info(bin_lookup, opts)
  data
end

#bin_range_lookup_request_with_http_info(bin_lookup, opts = {}) ⇒ Array<(Bin, Integer, Hash)>

Bin Lookup A bin range lookup service can be used to check what a card is, as seen by the gateway. Each card number&#39;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&#39;s country of origin 3. it&#39;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.

Parameters:

  • bin_lookup (BinLookup)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(Bin, Integer, Hash)>) —

    Bin data, response status code and response headers



104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 104

def bin_range_lookup_request_with_http_info(bin_lookup, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.bin_range_lookup_request ...'
  end
  # verify the required parameter 'bin_lookup' is set
  if @api_client.config.client_side_validation && bin_lookup.nil?
    fail ArgumentError, "Missing the required parameter 'bin_lookup' when calling AuthorisationAndPaymentApi.bin_range_lookup_request"
  end
  # resource path
  local_var_path = '/v6/bin'

  # 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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(bin_lookup)

  # return_type
  return_type = opts[:debug_return_type] || 'Bin'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.bin_range_lookup_request",
    :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: AuthorisationAndPaymentApi#bin_range_lookup_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#c_res_request(c_res_auth_request, opts = {}) ⇒ AuthResponse

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.

Parameters:

  • c_res_auth_request (CResAuthRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



162
163
164
165
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 162

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

#c_res_request_with_http_info(c_res_auth_request, opts = {}) ⇒ Array<(AuthResponse, Integer, Hash)>

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.

Parameters:

  • c_res_auth_request (CResAuthRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(AuthResponse, Integer, Hash)>) —

    AuthResponse data, response status code and response headers



172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 172

def c_res_request_with_http_info(c_res_auth_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.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 AuthorisationAndPaymentApi.c_res_request"
  end
  # resource path
  local_var_path = '/v6/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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(c_res_auth_request)

  # return_type
  return_type = opts[:debug_return_type] || 'AuthResponse'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.c_res_request",
    :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: AuthorisationAndPaymentApi#c_res_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#capture_request(capture_request, opts = {}) ⇒ Acknowledgement

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.

Parameters:

  • capture_request (CaptureRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



230
231
232
233
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 230

def capture_request(capture_request, opts = {})
  data, _status_code, _headers = capture_request_with_http_info(capture_request, opts)
  data
end

#capture_request_with_http_info(capture_request, opts = {}) ⇒ Array<(Acknowledgement, Integer, Hash)>

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.

Parameters:

  • capture_request (CaptureRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(Acknowledgement, Integer, Hash)>) —

    Acknowledgement data, response status code and response headers



240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 240

def capture_request_with_http_info(capture_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.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 AuthorisationAndPaymentApi.capture_request"
  end
  # resource path
  local_var_path = '/v6/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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(capture_request)

  # return_type
  return_type = opts[:debug_return_type] || 'Acknowledgement'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.capture_request",
    :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: AuthorisationAndPaymentApi#capture_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#pa_res_request(pa_res_auth_request, opts = {}) ⇒ AuthResponse

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.

Parameters:

  • pa_res_auth_request (PaResAuthRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



298
299
300
301
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 298

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

#pa_res_request_with_http_info(pa_res_auth_request, opts = {}) ⇒ Array<(AuthResponse, Integer, Hash)>

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.

Parameters:

  • pa_res_auth_request (PaResAuthRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(AuthResponse, Integer, Hash)>) —

    AuthResponse data, response status code and response headers



308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 308

def pa_res_request_with_http_info(pa_res_auth_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.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 AuthorisationAndPaymentApi.pa_res_request"
  end
  # resource path
  local_var_path = '/v6/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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(pa_res_auth_request)

  # return_type
  return_type = opts[:debug_return_type] || 'AuthResponse'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.pa_res_request",
    :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: AuthorisationAndPaymentApi#pa_res_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#refund_request(refund_request, opts = {}) ⇒ AuthResponse

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.

Parameters:

  • refund_request (RefundRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



366
367
368
369
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 366

def refund_request(refund_request, opts = {})
  data, _status_code, _headers = refund_request_with_http_info(refund_request, opts)
  data
end

#refund_request_with_http_info(refund_request, opts = {}) ⇒ Array<(AuthResponse, Integer, Hash)>

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.

Parameters:

  • refund_request (RefundRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(AuthResponse, Integer, Hash)>) —

    AuthResponse data, response status code and response headers



376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 376

def refund_request_with_http_info(refund_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.refund_request ...'
  end
  # verify the required parameter 'refund_request' is set
  if @api_client.config.client_side_validation && refund_request.nil?
    fail ArgumentError, "Missing the required parameter 'refund_request' when calling AuthorisationAndPaymentApi.refund_request"
  end
  # resource path
  local_var_path = '/v6/refund'

  # 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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(refund_request)

  # return_type
  return_type = opts[:debug_return_type] || 'AuthResponse'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.refund_request",
    :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: AuthorisationAndPaymentApi#refund_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#retrieval_request(retrieve_request, opts = {}) ⇒ AuthReferences

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.

Parameters:

  • retrieve_request (RetrieveRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



434
435
436
437
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 434

def retrieval_request(retrieve_request, opts = {})
  data, _status_code, _headers = retrieval_request_with_http_info(retrieve_request, opts)
  data
end

#retrieval_request_with_http_info(retrieve_request, opts = {}) ⇒ Array<(AuthReferences, Integer, Hash)>

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.

Parameters:

  • retrieve_request (RetrieveRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(AuthReferences, Integer, Hash)>) —

    AuthReferences data, response status code and response headers



444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 444

def retrieval_request_with_http_info(retrieve_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.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 AuthorisationAndPaymentApi.retrieval_request"
  end
  # resource path
  local_var_path = '/v6/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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(retrieve_request)

  # return_type
  return_type = opts[:debug_return_type] || 'AuthReferences'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.retrieval_request",
    :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: AuthorisationAndPaymentApi#retrieval_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end

#void_request(void_request, opts = {}) ⇒ Acknowledgement

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.

Parameters:

  • void_request (VoidRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:



502
503
504
505
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 502

def void_request(void_request, opts = {})
  data, _status_code, _headers = void_request_with_http_info(void_request, opts)
  data
end

#void_request_with_http_info(void_request, opts = {}) ⇒ Array<(Acknowledgement, Integer, Hash)>

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.

Parameters:

  • void_request (VoidRequest)
  • opts (Hash) (defaults to: {}) —

    the optional parameters

Returns:

  • (Array<(Acknowledgement, Integer, Hash)>) —

    Acknowledgement data, response status code and response headers



512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
 
# File 'lib/citypay_api_client/api/authorisation_and_payment_api__.rb', line 512

def void_request_with_http_info(void_request, opts = {})
  if @api_client.config.debugging
    @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.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 AuthorisationAndPaymentApi.void_request"
  end
  # resource path
  local_var_path = '/v6/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'
  content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
  if !content_type.nil?
      header_params['Content-Type'] = content_type
  end

  # form parameters
  form_params = opts[:form_params] || {}

  # http body (model)
  post_body = opts[:debug_body] || @api_client.object_to_http_body(void_request)

  # return_type
  return_type = opts[:debug_return_type] || 'Acknowledgement'

  # auth_names
  auth_names = opts[:debug_auth_names] || ['cp-api-key']

  new_options = opts.merge(
    :operation => :"AuthorisationAndPaymentApi.void_request",
    :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: AuthorisationAndPaymentApi#void_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
  end
  return data, status_code, headers
end