citypay_api_client 1.1.2 → 1.1.3

Sign up to get free protection for your applications and to get access to all the features.
Files changed (167) hide show
  1. checksums.yaml +4 -4
  2. data/Gemfile.lock +73 -0
  3. data/README.md +59 -32
  4. data/citypay_api_client.gemspec +1 -1
  5. data/docs/Acknowledgement.md +2 -2
  6. data/docs/AclCheckResponseModel.md +3 -3
  7. data/docs/AuthRequest.md +7 -7
  8. data/docs/AuthResponse.md +4 -4
  9. data/docs/AuthorisationAndPaymentApi.md +75 -231
  10. data/docs/Batch.md +1 -1
  11. data/docs/BatchProcessingApi.md +11 -11
  12. data/docs/BatchReportResponseModel.md +2 -2
  13. data/docs/BatchTransaction.md +1 -1
  14. data/docs/BatchTransactionReportRequest.md +22 -0
  15. data/docs/BatchTransactionReportResponse.md +24 -0
  16. data/docs/BatchTransactionResultModel.md +1 -1
  17. data/docs/Bin.md +2 -2
  18. data/docs/CaptureRequest.md +1 -1
  19. data/docs/Card.md +2 -2
  20. data/docs/CardHolderAccountApi.md +9 -5
  21. data/docs/ChargeRequest.md +7 -7
  22. data/docs/Decision.md +0 -2
  23. data/docs/DirectPostApi.md +2 -16
  24. data/docs/DirectPostRequest.md +7 -7
  25. data/docs/EventDataModel.md +2 -2
  26. data/docs/MerchantBatchReportRequest.md +28 -0
  27. data/docs/MerchantBatchReportResponse.md +24 -0
  28. data/docs/MerchantBatchResponse.md +30 -0
  29. data/docs/NetSummaryResponse.md +32 -0
  30. data/docs/PaylinkAdjustmentRequest.md +1 -1
  31. data/docs/PaylinkApi.md +141 -1
  32. data/docs/PaylinkBillPaymentTokenRequest.md +1 -1
  33. data/docs/PaylinkErrorCode.md +2 -2
  34. data/docs/PaylinkResendNotificationRequest.md +20 -0
  35. data/docs/PaylinkStateEvent.md +4 -4
  36. data/docs/PaylinkTokenCreated.md +11 -11
  37. data/docs/PaylinkTokenStatus.md +7 -7
  38. data/docs/PaylinkTokenStatusChangeRequest.md +7 -7
  39. data/docs/PaylinkTokenStatusChangeResponse.md +6 -2
  40. data/docs/PaymentIntent.md +42 -0
  41. data/docs/PaymentIntentReference.md +18 -0
  42. data/docs/RefundRequest.md +1 -1
  43. data/docs/RemittanceData.md +28 -0
  44. data/docs/RemittanceReportRequest.md +28 -0
  45. data/docs/RemittanceReportResponse.md +24 -0
  46. data/docs/RemittedClientData.md +44 -0
  47. data/docs/ReportingApi.md +378 -0
  48. data/docs/TokenisationResponseModel.md +1 -1
  49. data/lib/.DS_Store +0 -0
  50. data/lib/citypay_api_client/api/authorisation_and_payment_api__.rb +71 -3
  51. data/lib/citypay_api_client/api/batch_processing_api__.rb +7 -7
  52. data/lib/citypay_api_client/api/card_holder_account_api__.rb +4 -1
  53. data/lib/citypay_api_client/api/direct_post_api__.rb +5 -5
  54. data/lib/citypay_api_client/api/operational_functions_api__.rb +1 -1
  55. data/lib/citypay_api_client/api/paylink_api__.rb +138 -1
  56. data/lib/citypay_api_client/api/reporting_api__.rb +381 -0
  57. data/lib/citypay_api_client/api_client.rb +1 -1
  58. data/lib/citypay_api_client/api_error.rb +1 -1
  59. data/lib/citypay_api_client/configuration.rb +1 -1
  60. data/lib/citypay_api_client/models/account_create.rb +1 -1
  61. data/lib/citypay_api_client/models/account_status.rb +1 -1
  62. data/lib/citypay_api_client/models/acknowledgement.rb +1 -29
  63. data/lib/citypay_api_client/models/acl_check_request.rb +1 -1
  64. data/lib/citypay_api_client/models/acl_check_response_model.rb +2 -2
  65. data/lib/citypay_api_client/models/airline_advice.rb +1 -1
  66. data/lib/citypay_api_client/models/airline_segment.rb +1 -1
  67. data/lib/citypay_api_client/models/auth_reference.rb +1 -1
  68. data/lib/citypay_api_client/models/auth_references.rb +1 -1
  69. data/lib/citypay_api_client/models/auth_request.rb +10 -9
  70. data/lib/citypay_api_client/models/auth_response.rb +2 -2
  71. data/lib/citypay_api_client/models/batch.rb +2 -2
  72. data/lib/citypay_api_client/models/batch_report_request.rb +1 -1
  73. data/lib/citypay_api_client/models/batch_report_response_model.rb +2 -2
  74. data/lib/citypay_api_client/models/batch_transaction.rb +1 -1
  75. data/lib/citypay_api_client/models/batch_transaction_report_request.rb +234 -0
  76. data/lib/citypay_api_client/models/batch_transaction_report_response.rb +252 -0
  77. data/lib/citypay_api_client/models/batch_transaction_result_model.rb +1 -1
  78. data/lib/citypay_api_client/models/bin.rb +1 -1
  79. data/lib/citypay_api_client/models/bin_lookup.rb +1 -1
  80. data/lib/citypay_api_client/models/c_res_auth_request.rb +1 -1
  81. data/lib/citypay_api_client/models/capture_request.rb +1 -1
  82. data/lib/citypay_api_client/models/card.rb +1 -1
  83. data/lib/citypay_api_client/models/card_holder_account.rb +1 -1
  84. data/lib/citypay_api_client/models/card_status.rb +1 -1
  85. data/lib/citypay_api_client/models/charge_request.rb +10 -9
  86. data/lib/citypay_api_client/models/check_batch_status.rb +1 -1
  87. data/lib/citypay_api_client/models/check_batch_status_response.rb +1 -1
  88. data/lib/citypay_api_client/models/contact_details.rb +1 -1
  89. data/lib/citypay_api_client/models/decision.rb +2 -11
  90. data/lib/citypay_api_client/models/direct_post_request.rb +10 -9
  91. data/lib/citypay_api_client/models/direct_token_auth_request.rb +1 -1
  92. data/lib/citypay_api_client/models/domain_key_check_request.rb +1 -1
  93. data/lib/citypay_api_client/models/domain_key_request.rb +1 -1
  94. data/lib/citypay_api_client/models/domain_key_response.rb +1 -1
  95. data/lib/citypay_api_client/models/error.rb +1 -1
  96. data/lib/citypay_api_client/models/event_data_model.rb +1 -1
  97. data/lib/citypay_api_client/models/exists.rb +1 -1
  98. data/lib/citypay_api_client/models/external_mpi.rb +1 -1
  99. data/lib/citypay_api_client/models/list_merchants_response.rb +1 -1
  100. data/lib/citypay_api_client/models/mcc6012.rb +1 -1
  101. data/lib/citypay_api_client/models/merchant.rb +1 -1
  102. data/lib/citypay_api_client/models/merchant_batch_report_request.rb +265 -0
  103. data/lib/citypay_api_client/models/merchant_batch_report_response.rb +252 -0
  104. data/lib/citypay_api_client/models/merchant_batch_response.rb +301 -0
  105. data/lib/citypay_api_client/models/net_summary_response.rb +472 -0
  106. data/lib/citypay_api_client/models/pa_res_auth_request.rb +1 -1
  107. data/lib/citypay_api_client/models/paylink_address.rb +1 -1
  108. data/lib/citypay_api_client/models/paylink_adjustment_request.rb +1 -1
  109. data/lib/citypay_api_client/models/paylink_attachment_request.rb +1 -1
  110. data/lib/citypay_api_client/models/paylink_attachment_result.rb +1 -1
  111. data/lib/citypay_api_client/models/paylink_bill_payment_token_request.rb +1 -1
  112. data/lib/citypay_api_client/models/paylink_card_holder.rb +1 -1
  113. data/lib/citypay_api_client/models/paylink_cart.rb +1 -1
  114. data/lib/citypay_api_client/models/paylink_cart_item_model.rb +1 -1
  115. data/lib/citypay_api_client/models/paylink_config.rb +1 -1
  116. data/lib/citypay_api_client/models/paylink_custom_param.rb +1 -1
  117. data/lib/citypay_api_client/models/paylink_email_notification_path.rb +1 -1
  118. data/lib/citypay_api_client/models/paylink_error_code.rb +1 -1
  119. data/lib/citypay_api_client/models/paylink_field_guard_model.rb +1 -1
  120. data/lib/citypay_api_client/models/paylink_part_payments.rb +1 -1
  121. data/lib/citypay_api_client/models/paylink_resend_notification_request.rb +224 -0
  122. data/lib/citypay_api_client/models/paylink_sms_notification_path.rb +1 -1
  123. data/lib/citypay_api_client/models/paylink_state_event.rb +2 -2
  124. data/lib/citypay_api_client/models/paylink_token_created.rb +36 -8
  125. data/lib/citypay_api_client/models/paylink_token_request_model.rb +1 -1
  126. data/lib/citypay_api_client/models/paylink_token_status.rb +30 -2
  127. data/lib/citypay_api_client/models/paylink_token_status_change_request.rb +6 -7
  128. data/lib/citypay_api_client/models/paylink_token_status_change_response.rb +23 -3
  129. data/lib/citypay_api_client/models/paylink_ui.rb +1 -1
  130. data/lib/citypay_api_client/models/payment_intent.rb +479 -0
  131. data/lib/citypay_api_client/models/payment_intent_reference.rb +221 -0
  132. data/lib/citypay_api_client/models/ping.rb +1 -1
  133. data/lib/citypay_api_client/models/process_batch_request.rb +1 -1
  134. data/lib/citypay_api_client/models/process_batch_response.rb +1 -1
  135. data/lib/citypay_api_client/models/refund_request.rb +1 -1
  136. data/lib/citypay_api_client/models/register_card.rb +1 -1
  137. data/lib/citypay_api_client/models/remittance_data.rb +404 -0
  138. data/lib/citypay_api_client/models/remittance_report_request.rb +265 -0
  139. data/lib/citypay_api_client/models/remittance_report_response.rb +252 -0
  140. data/lib/citypay_api_client/models/remitted_client_data.rb +612 -0
  141. data/lib/citypay_api_client/models/request_challenged.rb +1 -1
  142. data/lib/citypay_api_client/models/retrieve_request.rb +1 -1
  143. data/lib/citypay_api_client/models/three_d_secure.rb +1 -1
  144. data/lib/citypay_api_client/models/tokenisation_response_model.rb +1 -1
  145. data/lib/citypay_api_client/models/void_request.rb +1 -1
  146. data/lib/citypay_api_client/version.rb +2 -2
  147. data/lib/citypay_api_client.rb +15 -2
  148. data/spec/.DS_Store +0 -0
  149. data/spec/api/reporting_api___spec.rb +99 -0
  150. data/spec/it_api_sandbox_spec.rb +0 -3
  151. data/spec/models/batch_transaction_report_request_spec.rb +47 -0
  152. data/spec/models/batch_transaction_report_response_spec.rb +53 -0
  153. data/spec/models/decision_spec.rb +0 -26
  154. data/spec/models/merchant_batch_report_request_spec.rb +65 -0
  155. data/spec/models/merchant_batch_report_response_spec.rb +53 -0
  156. data/spec/models/merchant_batch_response_spec.rb +71 -0
  157. data/spec/models/net_summary_response_spec.rb +77 -0
  158. data/spec/models/paylink_resend_notification_request_spec.rb +41 -0
  159. data/spec/models/payment_intent_reference_spec.rb +35 -0
  160. data/spec/models/payment_intent_spec.rb +107 -0
  161. data/spec/models/remittance_data_spec.rb +65 -0
  162. data/spec/models/remittance_report_request_spec.rb +65 -0
  163. data/spec/models/remittance_report_response_spec.rb +53 -0
  164. data/spec/models/remitted_client_data_spec.rb +113 -0
  165. data/spec/spec_helper.rb +1 -1
  166. metadata +124 -69
  167. data/spec/models/authen_required_spec.rb +0 -52
@@ -1,7 +1,7 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
4
+ # Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview <aside class=\"notice\"> Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. </aside> ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.
5
5
 
6
6
  Contact: support@citypay.com
7
7
  Generated by: https://openapi-generator.tech
@@ -19,7 +19,7 @@ module CityPayApiClient
19
19
  @api_client = api_client
20
20
  end
21
21
  # Authorisation
22
- # An authorisation process performs a standard transaction authorisation based on the provided parameters of its request. The CityPay gateway will route your transaction via an Acquiring bank for subsequent authorisation to the appropriate card schemes such as Visa or MasterCard. The authorisation API should be used for server environments to process transactions on demand and in realtime. The authorisation API can be used for multiple types of transactions including E-commerce, mail order, telephone order, customer present (keyed), continuous authority, pre-authorisation and others. CityPay will configure your account for the appropriate coding and this will perform transparently by the gateway. Data properties that are required, may depend on the environment you are conducting payment for. Our API aims to be flexible enough to cater for these structures. Our integration team will aid you in providing the necessary data to transact. ```json { \"RequestChallenged\": { \"acsurl\": \"https://bank.com/3DS/ACS\", \"creq\": \"SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\", \"merchantid\": 12345, \"transno\": 1, \"threedserver_trans_id\": \"d652d8d2-d74a-4264-a051-a7862b10d5d6\" } } ``` ## E-commerce workflows For E-commerce transactions requiring 3DS, the API contains a fully accredited in built mechanism to handle authentication. The Api and gateway has been accredited extensively with both Acquirers and Card Schemes to simplify the nature of these calls into a simple structure for authentication, preventing integrators from performing lengthy and a costly accreditations with Visa and MasterCard. 3D-secure has been around for a number of years and aims to shift the liability of a transaction away from a merchant back to the cardholder. A *liability shift* determines whether a card holder can charge back a transaction as unknown. Effectively the process asks for a card holder to authenticate the transaction prior to authorisation producing a Cardholder verification value (CAVV) and ecommerce indicator (ECI) as evidence of authorisation. 3DS version 1 has now been replaced by 3DS version 2 to provide secure customer authentication (SCA) in line with EU regulation. 3DSv2 is being phased out and any accounts using version 1 of the protocol is expected to be migrated by March 2022. Any new integrations should only consider 3DSv2 flows. ### 3DSv2 ```json { \"RequestChallenged\": { \"acsurl\": \"https://bank.com/3DS/ACS\", \"creq\": \"SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\", \"merchantid\": 12345, \"transno\": 1, \"threedserver_trans_id\": \"d652d8d2-d74a-4264-a051-a7862b10d5d6\" } } ``` ```xml <RequestChallenged> <acsurl>https://bank.com/3DS/ACS</acsurl> <creq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</creq> <merchantid>12345</merchantid> <transno>1</transno> <threedserver_trans_id>d652d8d2-d74a-4264-a051-a7862b10d5d6</threedserver_trans_id> </RequestChallenged> ``` CityPay support 3DS version 2.1 for Verified by Visa, MasterCard Identity Check and American Express SafeKey 2.1. Version 2.2 is currently in development however this will be a seamless upgrade for all integrations. #### 3-D Secure - None ![3DSv2 Frctionless Flow](images/3dsv2-no3d.png) A basic flow may involve no 3-D secure processing. This could happen if there is no ability to perform authentication. An enrollment check may apply an \"attempted\" resolution to processing. In this instance a transaction may not meet any liability shift. A transaction may result in a decline due to this. We are also able to prevent from transactions being presented for authorisation if this occurs. #### 3-D Secure - Frictionless ![3DSv2 Frctionless Flow](images/3dsv2-frictionless.png) E-commerce transactions supporting 3DSv2 can benefit from seamlessly authenticated transactions which may perform a \"frictionless\" flow. This method will authenticate low risk transactions with minimal impact to a standard authorisation flow. Our API simply performs this on behalf of you the developer, the merchant and cardholder. No redirection occurs and hence the flow is called frictionless and will appear as though a simple transaction authorisation has occurred. #### 3-D Secure - Challenge ![3DSv2 Frctionless Flow](images/3dsv2-challenge.png) A transaction that is deemed as higher risk my be \"challenged\". In this instance, the API will return a [request challenge](#requestchallenged) which will require your integration to forward the cardholder's browser to the given [ACS url](#acsurl). This should be performed by posting the [creq](#creq) value (the challenge request value). Once complete, the ACS will have already been in touch with our servers by sending us a result of the authentication known as `RReq`. To maintain session state, a parameter `threeDSSessionData` can be posted to the ACS url and will be returned alongside the `CRes` value. This will ensure that any controller code will be able to isolate state between calls. This field is to be used by your own systems rather than ours and may be any value which can uniquely identify your cardholder's session. As an option, we do provide a `threedserver_trans_id` value in the `RequestChallenged` packet which can be used for the `threeDSSessionData` value as it is used to uniquely identify the 3D-Secure session. A common method of maintaining state is to provide a session related query string value in the `merchant_termurl` value (also known as the `notificationUrl`). For example providing a url of `https://mystore.com/checkout?token=asny2348w4561..` could return the user directly back to their session with your environment. Once you have received a `cres` post from the ACS authentication service, this should be POSTed to the [cres](#cres) endpoint to perform full authorisation processing. Please note that the CRes returned to us is purely a mechanism of acknowledging that transactions should be committed for authorisation. The ACS by this point will have sent us the verification value (CAVV) to perform a liability shift. The CRes value will be validated for receipt of the CAVV and subsequently may return response codes illustrating this. To forward the user to the ACS, we recommend a simple auto submit HTML form. > Simple auto submit HTML form ```html <html lang=\"en\"> <head> <title>Forward to ACS</title> <script type=\"text/javascript\"> function onLoadEvent() { document.acs.submit(); } </script> <noscript>You will require JavaScript to be enabled to complete this transaction</noscript> </head> <body onload=\"onLoadEvent();\"> <form name=\"acs\" action=\"{{ACSURL from Response}}\" method=\"POST\"> <input type=\"hidden\" name=\"creq\" value=\"{{CReq Packet from Response}}\" /> <input type=\"hidden\" name=\"threeDSSessionData\" value=\"{{session-identifier}}\" /> </form> </body> </html> ``` A full ACS test suite is available for 3DSv2 testing. ### Testing 3DSv2 Integrations The API provides a mock 3dsV2 handler which performs a number of scenarios based on the value of the CSC in the request. | CSC Value | Behaviour | |-----------|-----------| | 731 | Frictionless processing - Not authenticated | | 732 | Frictionless processing - Account verification count not be performed | | 733 | Frictionless processing - Verification Rejected | | 741 | Frictionless processing - Attempts Processing | | 750 | Frictionless processing - Authenticated | | 761 | Triggers an error message | | Any | Challenge Request | #### 3DSv1 **Please note that 3DSv1 should now be considered as deprecated.** ```json { \"AuthenticationRequired\": { \"acsurl\": \"https://bank.com/3DS/ACS\", \"pareq\": \"SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...\", \"md\": \"WQgZXZlcnl0aGluZyBiZW\" } } ``` ```xml <AuthenticationRequired> <acsurl>https://bank.com/3DS/ACS</acsurl> <pareq>SXQgd2FzIHRoZSBiZXN0IG9mIHRpbWVzLCBpdCB3YXMgdGhlIHdvcnN00...</pareq> <md>WQgZXZlcnl0aGluZyBiZW</md> </AuthenticationRequired> ``` For E-commerce transactions requiring 3DSv1, the API contains a built in MPI which will be called to check whether the card is participating in 3DSv1 with Verified by Visa or MasterCard SecureCode. We only support Amex SafeKey with 3DSv2. Should the card be enrolled, a payer request (PAReq) value will be created and returned back as an [authentication required](#authenticationrequired) response object. Your system will need to process this authentication packet and forward the user's browser to an authentication server (ACS) to gain the user's authentication. Once complete, the ACS will produce a HTTP `POST` call back to the URL supplied in the authentication request as `merchant_termurl`. This URL should behave as a controller and handle the post data from the ACS and on a forked server to server HTTP request, forward this data to the [pares authentication url](#pares) for subsequent authorisation processing. You may prefer to provide a processing page whilst this is being processed. Processing with our systems should be relatively quick and be between 500ms - 3000ms however it is desirable to let the user see that something is happening rather than a pending browser. The main reason for ensuring that this controller is two fold: 1. We are never in control of the user's browser in a server API call 2. The controller is actioned on your site to ensure that any post actions from authorisation can be executed in real time To forward the user to the ACS, we recommend a simple auto submit HTML form. > Simple auto submit HTML form ```html <html lang=\"en\"> <head> <title>Forward to ACS</title> <script type=\"text/javascript\"> function onLoadEvent() { document.acs.submit(); } </script> <noscript>You will require JavaScript to be enabled to complete this transaction</noscript> </head> <body onload=\"onLoadEvent();\"> <form name=\"acs\" action=\"{{ACSURL from Response}}\" method=\"POST\"> <input type=\"hidden\" name=\"PaReq\" value=\"{{PaReq Packet from Response}}\" /> <input type=\"hidden\" name=\"TermUrl\" value=\"{{Your Controller}}\" /> <input type=\"hidden\" name=\"MD\" value=\"{{MD From Response}}\" /> </form> </body> </html> ``` Please note that 3DSv1 is being phased out due to changes to strong customer authentication mechanisms. 3DSv2 addresses this and will solidify the authorisation and confirmation process. We provide a Test ACS for full 3DSv1 integration testing that simulates an ACS.
22
+ # Performs a request for authorisation for a card payment request.
23
23
  # @param auth_request [AuthRequest]
24
24
  # @param [Hash] opts the optional parameters
25
25
  # @return [Decision]
@@ -29,7 +29,7 @@ module CityPayApiClient
29
29
  end
30
30
 
31
31
  # Authorisation
32
- # 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. &#x60;&#x60;&#x60;json { \&quot;RequestChallenged\&quot;: { \&quot;acsurl\&quot;: \&quot;https://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; ## E-commerce workflows For E-commerce transactions requiring 3DS, the API contains a fully accredited in built mechanism to handle authentication. The Api and gateway has been accredited extensively with both Acquirers and Card Schemes to simplify the nature of these calls into a simple structure for authentication, preventing integrators from performing lengthy and a costly accreditations with Visa and MasterCard. 3D-secure has been around for a number of years and aims to shift the liability of a transaction away from a merchant back to the cardholder. A *liability shift* determines whether a card holder can charge back a transaction as unknown. Effectively the process asks for a card holder to authenticate the transaction prior to authorisation producing a Cardholder verification value (CAVV) and ecommerce indicator (ECI) as evidence of authorisation. 3DS version 1 has now been replaced by 3DS version 2 to provide secure customer authentication (SCA) in line with EU regulation. 3DSv2 is being phased out and any accounts using version 1 of the protocol is expected to be migrated by March 2022. Any new integrations should only consider 3DSv2 flows. ### 3DSv2 &#x60;&#x60;&#x60;json { \&quot;RequestChallenged\&quot;: { \&quot;acsurl\&quot;: \&quot;https://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;https://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;https://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;{{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;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;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. &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;{{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.
32
+ # Performs a request for authorisation for a card payment request.
33
33
  # @param auth_request [AuthRequest]
34
34
  # @param [Hash] opts the optional parameters
35
35
  # @return [Array<(Decision, Integer, Hash)>] Decision data, response status code and response headers
@@ -290,6 +290,74 @@ module CityPayApiClient
290
290
  return data, status_code, headers
291
291
  end
292
292
 
293
+ # Create a Payment Intent
294
+ # This endpoint initiates the creation of a payment intent, which is a precursor to processing a payment. A payment intent captures the details of a prospective payment transaction, including the payment amount, currency, and associated billing and shipping information.
295
+ # @param payment_intent [PaymentIntent]
296
+ # @param [Hash] opts the optional parameters
297
+ # @return [PaymentIntentReference]
298
+ def create_payment_intent(payment_intent, opts = {})
299
+ data, _status_code, _headers = create_payment_intent_with_http_info(payment_intent, opts)
300
+ data
301
+ end
302
+
303
+ # Create a Payment Intent
304
+ # This endpoint initiates the creation of a payment intent, which is a precursor to processing a payment. A payment intent captures the details of a prospective payment transaction, including the payment amount, currency, and associated billing and shipping information.
305
+ # @param payment_intent [PaymentIntent]
306
+ # @param [Hash] opts the optional parameters
307
+ # @return [Array<(PaymentIntentReference, Integer, Hash)>] PaymentIntentReference data, response status code and response headers
308
+ def create_payment_intent_with_http_info(payment_intent, opts = {})
309
+ if @api_client.config.debugging
310
+ @api_client.config.logger.debug 'Calling API: AuthorisationAndPaymentApi.create_payment_intent ...'
311
+ end
312
+ # verify the required parameter 'payment_intent' is set
313
+ if @api_client.config.client_side_validation && payment_intent.nil?
314
+ fail ArgumentError, "Missing the required parameter 'payment_intent' when calling AuthorisationAndPaymentApi.create_payment_intent"
315
+ end
316
+ # resource path
317
+ local_var_path = '/v6/intent/create'
318
+
319
+ # query parameters
320
+ query_params = opts[:query_params] || {}
321
+
322
+ # header parameters
323
+ header_params = opts[:header_params] || {}
324
+ # HTTP header 'Accept' (if needed)
325
+ header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
326
+ # HTTP header 'Content-Type'
327
+ content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
328
+ if !content_type.nil?
329
+ header_params['Content-Type'] = content_type
330
+ end
331
+
332
+ # form parameters
333
+ form_params = opts[:form_params] || {}
334
+
335
+ # http body (model)
336
+ post_body = opts[:debug_body] || @api_client.object_to_http_body(payment_intent)
337
+
338
+ # return_type
339
+ return_type = opts[:debug_return_type] || 'PaymentIntentReference'
340
+
341
+ # auth_names
342
+ auth_names = opts[:debug_auth_names] || ['cp-api-key']
343
+
344
+ new_options = opts.merge(
345
+ :operation => :"AuthorisationAndPaymentApi.create_payment_intent",
346
+ :header_params => header_params,
347
+ :query_params => query_params,
348
+ :form_params => form_params,
349
+ :body => post_body,
350
+ :auth_names => auth_names,
351
+ :return_type => return_type
352
+ )
353
+
354
+ data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
355
+ if @api_client.config.debugging
356
+ @api_client.config.logger.debug "API called: AuthorisationAndPaymentApi#create_payment_intent\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
357
+ end
358
+ return data, status_code, headers
359
+ end
360
+
293
361
  # PaRes
294
362
  # 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.
295
363
  # @param pa_res_auth_request [PaResAuthRequest]
@@ -1,7 +1,7 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
4
+ # Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview <aside class=\"notice\"> Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. </aside> ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.
5
5
 
6
6
  Contact: support@citypay.com
7
7
  Generated by: https://openapi-generator.tech
@@ -86,8 +86,8 @@ module CityPayApiClient
86
86
  return data, status_code, headers
87
87
  end
88
88
 
89
- # BatchReportRequest
90
- # The report for a given batch.
89
+ # Batch Retrieve Request
90
+ # Obtains a batch and installment (BIS) report for a given batch id.
91
91
  # @param batch_report_request [BatchReportRequest]
92
92
  # @param [Hash] opts the optional parameters
93
93
  # @return [BatchReportResponseModel]
@@ -96,8 +96,8 @@ module CityPayApiClient
96
96
  data
97
97
  end
98
98
 
99
- # BatchReportRequest
100
- # The report for a given batch.
99
+ # Batch Retrieve Request
100
+ # Obtains a batch and installment (BIS) report for a given batch id.
101
101
  # @param batch_report_request [BatchReportRequest]
102
102
  # @param [Hash] opts the optional parameters
103
103
  # @return [Array<(BatchReportResponseModel, Integer, Hash)>] BatchReportResponseModel data, response status code and response headers
@@ -154,7 +154,7 @@ module CityPayApiClient
154
154
  return data, status_code, headers
155
155
  end
156
156
 
157
- # CheckBatchStatus
157
+ # Check Batch Status
158
158
  # The operation is used to retrieve the status of a batch process.
159
159
  # @param check_batch_status [CheckBatchStatus]
160
160
  # @param [Hash] opts the optional parameters
@@ -164,7 +164,7 @@ module CityPayApiClient
164
164
  data
165
165
  end
166
166
 
167
- # CheckBatchStatus
167
+ # Check Batch Status
168
168
  # The operation is used to retrieve the status of a batch process.
169
169
  # @param check_batch_status [CheckBatchStatus]
170
170
  # @param [Hash] opts the optional parameters
@@ -1,7 +1,7 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
4
+ # Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview <aside class=\"notice\"> Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. </aside> ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.
5
5
 
6
6
  Contact: support@citypay.com
7
7
  Generated by: https://openapi-generator.tech
@@ -23,6 +23,7 @@ module CityPayApiClient
23
23
  # @param accountid [String] The account id that refers to the customer&#39;s account no. This value will have been provided when setting up the card holder account.
24
24
  # @param card_id [String] The id of the card that is presented by a call to retrieve a card holder account.
25
25
  # @param [Hash] opts the optional parameters
26
+ # @option opts [Boolean] :force Requests that the item is forced immediately.
26
27
  # @return [Acknowledgement]
27
28
  def account_card_delete_request(accountid, card_id, opts = {})
28
29
  data, _status_code, _headers = account_card_delete_request_with_http_info(accountid, card_id, opts)
@@ -34,6 +35,7 @@ module CityPayApiClient
34
35
  # @param accountid [String] The account id that refers to the customer&#39;s account no. This value will have been provided when setting up the card holder account.
35
36
  # @param card_id [String] The id of the card that is presented by a call to retrieve a card holder account.
36
37
  # @param [Hash] opts the optional parameters
38
+ # @option opts [Boolean] :force Requests that the item is forced immediately.
37
39
  # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
38
40
  def account_card_delete_request_with_http_info(accountid, card_id, opts = {})
39
41
  if @api_client.config.debugging
@@ -52,6 +54,7 @@ module CityPayApiClient
52
54
 
53
55
  # query parameters
54
56
  query_params = opts[:query_params] || {}
57
+ query_params[:'force'] = opts[:'force'] if !opts[:'force'].nil?
55
58
 
56
59
  # header parameters
57
60
  header_params = opts[:header_params] || {}
@@ -1,7 +1,7 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
4
+ # Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview <aside class=\"notice\"> Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. </aside> ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.
5
5
 
6
6
  Contact: support@citypay.com
7
7
  Generated by: https://openapi-generator.tech
@@ -167,7 +167,7 @@ module CityPayApiClient
167
167
  end
168
168
 
169
169
  # Direct Post Auth Request
170
- # Used to initiate a direct post request transaction flow. <pre class=\"inline-code language-bash\"> <code> curl https://api.citypay.com/direct/auth?cp-domain-key=n834ytqp84y... \\ -d \"amount=7500&identifier=example_trans&cardnumber=4000000000000002&expmonth=9&expyear=2028&bill_to_postcode=L1+7ZW </code> </pre>.
170
+ # Used to initiate a direct post request transaction flow.
171
171
  # @param direct_post_request [DirectPostRequest]
172
172
  # @param [Hash] opts the optional parameters
173
173
  # @return [AuthResponse]
@@ -177,7 +177,7 @@ module CityPayApiClient
177
177
  end
178
178
 
179
179
  # Direct Post Auth Request
180
- # Used to initiate a direct post request transaction flow. &lt;pre class&#x3D;\&quot;inline-code language-bash\&quot;&gt; &lt;code&gt; curl https://api.citypay.com/direct/auth?cp-domain-key&#x3D;n834ytqp84y... \\ -d \&quot;amount&#x3D;7500&amp;identifier&#x3D;example_trans&amp;cardnumber&#x3D;4000000000000002&amp;expmonth&#x3D;9&amp;expyear&#x3D;2028&amp;bill_to_postcode&#x3D;L1+7ZW &lt;/code&gt; &lt;/pre&gt;.
180
+ # Used to initiate a direct post request transaction flow.
181
181
  # @param direct_post_request [DirectPostRequest]
182
182
  # @param [Hash] opts the optional parameters
183
183
  # @return [Array<(AuthResponse, Integer, Hash)>] AuthResponse data, response status code and response headers
@@ -235,7 +235,7 @@ module CityPayApiClient
235
235
  end
236
236
 
237
237
  # Direct Post Tokenise Request
238
- # Used to initiate a direct post request transaction flow. <pre class=\"inline-code language-bash\"> <code> curl https://api.citypay.com/v6/direct?cp-domain-key=n834ytqp84y... \\ -d \"amount=7500&identifier=example_trans&cardnumber=4000000000000002&expmonth=9&expyear=2028&bill_to_postcode=L1+7ZW </code> </pre>.
238
+ # Used to initiate a direct post request transaction flow.
239
239
  # @param direct_post_request [DirectPostRequest]
240
240
  # @param [Hash] opts the optional parameters
241
241
  # @return [AuthResponse]
@@ -245,7 +245,7 @@ module CityPayApiClient
245
245
  end
246
246
 
247
247
  # Direct Post Tokenise Request
248
- # Used to initiate a direct post request transaction flow. &lt;pre class&#x3D;\&quot;inline-code language-bash\&quot;&gt; &lt;code&gt; curl https://api.citypay.com/v6/direct?cp-domain-key&#x3D;n834ytqp84y... \\ -d \&quot;amount&#x3D;7500&amp;identifier&#x3D;example_trans&amp;cardnumber&#x3D;4000000000000002&amp;expmonth&#x3D;9&amp;expyear&#x3D;2028&amp;bill_to_postcode&#x3D;L1+7ZW &lt;/code&gt; &lt;/pre&gt;.
248
+ # Used to initiate a direct post request transaction flow.
249
249
  # @param direct_post_request [DirectPostRequest]
250
250
  # @param [Hash] opts the optional parameters
251
251
  # @return [Array<(AuthResponse, Integer, Hash)>] AuthResponse data, response status code and response headers
@@ -1,7 +1,7 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
4
+ # Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview <aside class=\"notice\"> Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. </aside> ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.
5
5
 
6
6
  Contact: support@citypay.com
7
7
  Generated by: https://openapi-generator.tech
@@ -1,7 +1,7 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is an HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokenized payments using cardholder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](https://citypay.github.io/api-docs/payment-api/#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive cardholder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
4
+ # Welcome to the CityPay API, a robust HTTP API payment solution designed for seamless server-to-server transactional processing. Our API facilitates a wide array of payment operations, catering to diverse business needs. Whether you're integrating Internet payments, handling Mail Order/Telephone Order (MOTO) transactions, managing Subscriptions with Recurring and Continuous Authority payments, or navigating the complexities of 3-D Secure authentication, our API is equipped to support your requirements. Additionally, we offer functionalities for Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids, and Completion processing, alongside the capability for tokenised payments. ## Compliance and Security Overview <aside class=\"notice\"> Ensuring the security of payment transactions and compliance with industry standards is paramount. Our API is designed with stringent security measures and compliance protocols to safeguard sensitive information and meet the rigorous requirements of Visa, MasterCard, and the PCI Security Standards Council. </aside> ### Key Compliance and Security Measures * **TLS Encryption**: All data transmissions must utilise TLS version 1.2 or higher, employing [strong cryptography](#enabled-tls-ciphers). Our infrastructure strictly enforces this requirement to maintain the integrity and confidentiality of data in transit. We conduct regular scans and assessments of our TLS endpoints to identify and mitigate vulnerabilities. * **Data Storage Prohibitions**: Storing sensitive cardholder data (CHD), such as the card security code (CSC) or primary account number (PAN), is strictly prohibited. Our API is designed to minimize your exposure to sensitive data, thereby reducing your compliance burden. * **Data Masking**: For consumer protection and compliance, full card numbers must not be displayed on receipts or any customer-facing materials. Our API automatically masks PANs, displaying only the last four digits to facilitate safe receipt generation. * **Network Scans**: If your application is web-based, regular scans of your hosting environment are mandatory to identify and rectify potential vulnerabilities. This proactive measure is crucial for maintaining a secure and compliant online presence. * **PCI Compliance**: Adherence to PCI DSS standards is not optional; it's a requirement for operating securely and legally in the payments ecosystem. For detailed information on compliance requirements and resources, please visit the PCI Security Standards Council website [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/). * **Request Validation**: Our API includes mechanisms to verify the legitimacy of each request, ensuring it pertains to a valid account and originates from a trusted source. We leverage remote IP address verification alongside sophisticated application firewall technologies to thwart a wide array of common security threats. ## Getting Started Before integrating with the CityPay API, ensure your application and development practices align with the outlined compliance and security measures. This preparatory step is crucial for a smooth integration process and the long-term success of your payment processing operations. For further details on API endpoints, request/response formats, and code examples, proceed to the subsequent sections of our documentation. Our aim is to provide you with all the necessary tools and information to integrate our payment processing capabilities seamlessly into your application. Thank you for choosing CityPay API. We look forward to supporting your payment processing needs with our secure, compliant, and versatile API solution.
5
5
 
6
6
  Contact: support@citypay.com
7
7
  Generated by: https://openapi-generator.tech
@@ -92,6 +92,69 @@ module CityPayApiClient
92
92
  return data, status_code, headers
93
93
  end
94
94
 
95
+ # Cancel a Paylink Token
96
+ # Marks a Paylink Token as cancelled. This cancels the Token for any future request for processing.
97
+ # @param token [String] The token returned by the create token process.
98
+ # @param [Hash] opts the optional parameters
99
+ # @return [Acknowledgement]
100
+ def token_cancel_request(token, opts = {})
101
+ data, _status_code, _headers = token_cancel_request_with_http_info(token, opts)
102
+ data
103
+ end
104
+
105
+ # Cancel a Paylink Token
106
+ # Marks a Paylink Token as cancelled. This cancels the Token for any future request for processing.
107
+ # @param token [String] The token returned by the create token process.
108
+ # @param [Hash] opts the optional parameters
109
+ # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
110
+ def token_cancel_request_with_http_info(token, opts = {})
111
+ if @api_client.config.debugging
112
+ @api_client.config.logger.debug 'Calling API: PaylinkApi.token_cancel_request ...'
113
+ end
114
+ # verify the required parameter 'token' is set
115
+ if @api_client.config.client_side_validation && token.nil?
116
+ fail ArgumentError, "Missing the required parameter 'token' when calling PaylinkApi.token_cancel_request"
117
+ end
118
+ # resource path
119
+ local_var_path = '/paylink/{token}/cancel'.sub('{' + 'token' + '}', CGI.escape(token.to_s))
120
+
121
+ # query parameters
122
+ query_params = opts[:query_params] || {}
123
+
124
+ # header parameters
125
+ header_params = opts[:header_params] || {}
126
+ # HTTP header 'Accept' (if needed)
127
+ header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
128
+
129
+ # form parameters
130
+ form_params = opts[:form_params] || {}
131
+
132
+ # http body (model)
133
+ post_body = opts[:debug_body]
134
+
135
+ # return_type
136
+ return_type = opts[:debug_return_type] || 'Acknowledgement'
137
+
138
+ # auth_names
139
+ auth_names = opts[:debug_auth_names] || ['cp-api-key']
140
+
141
+ new_options = opts.merge(
142
+ :operation => :"PaylinkApi.token_cancel_request",
143
+ :header_params => header_params,
144
+ :query_params => query_params,
145
+ :form_params => form_params,
146
+ :body => post_body,
147
+ :auth_names => auth_names,
148
+ :return_type => return_type
149
+ )
150
+
151
+ data, status_code, headers = @api_client.call_api(:PUT, local_var_path, new_options)
152
+ if @api_client.config.debugging
153
+ @api_client.config.logger.debug "API called: PaylinkApi#token_cancel_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
154
+ end
155
+ return data, status_code, headers
156
+ end
157
+
95
158
  # Paylink Token Audit
96
159
  # Allows for the changes to a pre-existing token.
97
160
  # @param paylink_token_status_change_request [PaylinkTokenStatusChangeRequest]
@@ -548,6 +611,80 @@ module CityPayApiClient
548
611
  return data, status_code, headers
549
612
  end
550
613
 
614
+ # Resend a notification for Paylink Token
615
+ # Resend a notification for Paylink Token.
616
+ # @param token [String] The token returned by the create token process.
617
+ # @param paylink_resend_notification_request [PaylinkResendNotificationRequest]
618
+ # @param [Hash] opts the optional parameters
619
+ # @return [Acknowledgement]
620
+ def token_resend_notification_request(token, paylink_resend_notification_request, opts = {})
621
+ data, _status_code, _headers = token_resend_notification_request_with_http_info(token, paylink_resend_notification_request, opts)
622
+ data
623
+ end
624
+
625
+ # Resend a notification for Paylink Token
626
+ # Resend a notification for Paylink Token.
627
+ # @param token [String] The token returned by the create token process.
628
+ # @param paylink_resend_notification_request [PaylinkResendNotificationRequest]
629
+ # @param [Hash] opts the optional parameters
630
+ # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
631
+ def token_resend_notification_request_with_http_info(token, paylink_resend_notification_request, opts = {})
632
+ if @api_client.config.debugging
633
+ @api_client.config.logger.debug 'Calling API: PaylinkApi.token_resend_notification_request ...'
634
+ end
635
+ # verify the required parameter 'token' is set
636
+ if @api_client.config.client_side_validation && token.nil?
637
+ fail ArgumentError, "Missing the required parameter 'token' when calling PaylinkApi.token_resend_notification_request"
638
+ end
639
+ # verify the required parameter 'paylink_resend_notification_request' is set
640
+ if @api_client.config.client_side_validation && paylink_resend_notification_request.nil?
641
+ fail ArgumentError, "Missing the required parameter 'paylink_resend_notification_request' when calling PaylinkApi.token_resend_notification_request"
642
+ end
643
+ # resource path
644
+ local_var_path = '/paylink/{token}/resend-notification'.sub('{' + 'token' + '}', CGI.escape(token.to_s))
645
+
646
+ # query parameters
647
+ query_params = opts[:query_params] || {}
648
+
649
+ # header parameters
650
+ header_params = opts[:header_params] || {}
651
+ # HTTP header 'Accept' (if needed)
652
+ header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
653
+ # HTTP header 'Content-Type'
654
+ content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
655
+ if !content_type.nil?
656
+ header_params['Content-Type'] = content_type
657
+ end
658
+
659
+ # form parameters
660
+ form_params = opts[:form_params] || {}
661
+
662
+ # http body (model)
663
+ post_body = opts[:debug_body] || @api_client.object_to_http_body(paylink_resend_notification_request)
664
+
665
+ # return_type
666
+ return_type = opts[:debug_return_type] || 'Acknowledgement'
667
+
668
+ # auth_names
669
+ auth_names = opts[:debug_auth_names] || ['cp-api-key']
670
+
671
+ new_options = opts.merge(
672
+ :operation => :"PaylinkApi.token_resend_notification_request",
673
+ :header_params => header_params,
674
+ :query_params => query_params,
675
+ :form_params => form_params,
676
+ :body => post_body,
677
+ :auth_names => auth_names,
678
+ :return_type => return_type
679
+ )
680
+
681
+ data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
682
+ if @api_client.config.debugging
683
+ @api_client.config.logger.debug "API called: PaylinkApi#token_resend_notification_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
684
+ end
685
+ return data, status_code, headers
686
+ end
687
+
551
688
  # Paylink Token Status
552
689
  # Obtains the full status of a given Paylink Token.
553
690
  # @param token [String] The token returned by the create token process.