citypay_api_client 1.1.1 → 1.1.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (212) hide show
  1. checksums.yaml +4 -4
  2. data/Gemfile.lock +73 -0
  3. data/README.md +65 -37
  4. data/citypay_api_client.gemspec +4 -3
  5. data/docs/Acknowledgement.md +2 -2
  6. data/docs/AclCheckResponseModel.md +3 -3
  7. data/docs/AirlineAdvice.md +1 -1
  8. data/docs/AuthRequest.md +9 -7
  9. data/docs/AuthResponse.md +9 -5
  10. data/docs/AuthorisationAndPaymentApi.md +145 -10
  11. data/docs/Batch.md +1 -1
  12. data/docs/BatchProcessingApi.md +24 -20
  13. data/docs/BatchReportResponseModel.md +2 -2
  14. data/docs/BatchTransaction.md +1 -1
  15. data/docs/BatchTransactionReportRequest.md +22 -0
  16. data/docs/BatchTransactionReportResponse.md +24 -0
  17. data/docs/BatchTransactionResultModel.md +6 -2
  18. data/docs/Bin.md +2 -2
  19. data/docs/CaptureRequest.md +1 -1
  20. data/docs/Card.md +3 -3
  21. data/docs/CardHolderAccountApi.md +73 -14
  22. data/docs/ChargeRequest.md +8 -6
  23. data/docs/ContactDetails.md +11 -11
  24. data/docs/Decision.md +0 -2
  25. data/docs/DirectPostApi.md +26 -16
  26. data/docs/DirectPostRequest.md +9 -7
  27. data/docs/EventDataModel.md +2 -2
  28. data/docs/MerchantBatchReportRequest.md +28 -0
  29. data/docs/MerchantBatchReportResponse.md +24 -0
  30. data/docs/MerchantBatchResponse.md +30 -0
  31. data/docs/NetSummaryResponse.md +32 -0
  32. data/docs/OperationalFunctionsApi.md +28 -8
  33. data/docs/PaylinkAdjustmentRequest.md +1 -1
  34. data/docs/PaylinkApi.md +337 -21
  35. data/docs/PaylinkBillPaymentTokenRequest.md +1 -1
  36. data/docs/PaylinkCustomParam.md +3 -1
  37. data/docs/PaylinkErrorCode.md +2 -2
  38. data/docs/PaylinkFieldGuardModel.md +1 -1
  39. data/docs/PaylinkResendNotificationRequest.md +20 -0
  40. data/docs/PaylinkStateEvent.md +4 -4
  41. data/docs/PaylinkTokenCreated.md +11 -11
  42. data/docs/PaylinkTokenRequestModel.md +4 -0
  43. data/docs/PaylinkTokenStatus.md +7 -7
  44. data/docs/PaylinkTokenStatusChangeRequest.md +7 -7
  45. data/docs/PaylinkTokenStatusChangeResponse.md +6 -2
  46. data/docs/PaymentIntent.md +42 -0
  47. data/docs/PaymentIntentReference.md +18 -0
  48. data/docs/RefundRequest.md +1 -1
  49. data/docs/RegisterCard.md +1 -1
  50. data/docs/RemittanceData.md +28 -0
  51. data/docs/RemittanceReportRequest.md +28 -0
  52. data/docs/RemittanceReportResponse.md +24 -0
  53. data/docs/RemittedClientData.md +44 -0
  54. data/docs/ReportingApi.md +378 -0
  55. data/docs/ThreeDSecure.md +1 -1
  56. data/docs/TokenisationResponseModel.md +3 -3
  57. data/docs/images/3dsv1-challenge.png +0 -0
  58. data/docs/images/3dsv2-challenge.png +0 -0
  59. data/docs/images/3dsv2-frictionless.png +0 -0
  60. data/docs/images/3dsv2-method-challenge.png +0 -0
  61. data/docs/images/3dsv2-method-frictionless.png +0 -0
  62. data/docs/images/3dsv2-no3d.png +0 -0
  63. data/docs/images/citypay-logo.svg +1 -0
  64. data/docs/images/direct-post-flow.png +0 -0
  65. data/docs/images/favicon.ico +0 -0
  66. data/docs/images/header.png +0 -0
  67. data/docs/images/logo.ai +1913 -4
  68. data/docs/images/logo.png +0 -0
  69. data/docs/images/logo.svg +1 -0
  70. data/docs/images/merchant-BPS-workflow.png +0 -0
  71. data/docs/images/paylink-field-guards.png +0 -0
  72. data/lib/citypay_api_client/api/authorisation_and_payment_api__.rb +72 -4
  73. data/lib/citypay_api_client/api/batch_processing_api__.rb +15 -15
  74. data/lib/citypay_api_client/api/card_holder_account_api__.rb +5 -2
  75. data/lib/citypay_api_client/api/direct_post_api__.rb +9 -9
  76. data/lib/citypay_api_client/api/operational_functions_api__.rb +3 -3
  77. data/lib/citypay_api_client/api/paylink_api__.rb +163 -26
  78. data/lib/citypay_api_client/api/reporting_api__.rb +381 -0
  79. data/lib/citypay_api_client/api_client.rb +24 -22
  80. data/lib/citypay_api_client/api_error.rb +3 -2
  81. data/lib/citypay_api_client/configuration.rb +28 -9
  82. data/lib/citypay_api_client/models/account_create.rb +17 -20
  83. data/lib/citypay_api_client/models/account_status.rb +15 -20
  84. data/lib/citypay_api_client/models/acknowledgement.rb +21 -46
  85. data/lib/citypay_api_client/models/acl_check_request.rb +17 -20
  86. data/lib/citypay_api_client/models/acl_check_response_model.rb +16 -21
  87. data/lib/citypay_api_client/models/airline_advice.rb +45 -29
  88. data/lib/citypay_api_client/models/airline_segment.rb +35 -22
  89. data/lib/citypay_api_client/models/auth_reference.rb +41 -26
  90. data/lib/citypay_api_client/models/auth_references.rb +15 -20
  91. data/lib/citypay_api_client/models/auth_request.rb +72 -34
  92. data/lib/citypay_api_client/models/auth_response.rb +46 -23
  93. data/lib/citypay_api_client/models/authen_required.rb +15 -20
  94. data/lib/citypay_api_client/models/batch.rb +25 -22
  95. data/lib/citypay_api_client/models/batch_report_request.rb +23 -22
  96. data/lib/citypay_api_client/models/batch_report_response_model.rb +28 -21
  97. data/lib/citypay_api_client/models/batch_transaction.rb +25 -22
  98. data/lib/citypay_api_client/models/batch_transaction_report_request.rb +234 -0
  99. data/lib/citypay_api_client/models/batch_transaction_report_response.rb +252 -0
  100. data/lib/citypay_api_client/models/batch_transaction_result_model.rb +53 -22
  101. data/lib/citypay_api_client/models/bin.rb +15 -20
  102. data/lib/citypay_api_client/models/bin_lookup.rb +17 -20
  103. data/lib/citypay_api_client/models/c_res_auth_request.rb +15 -20
  104. data/lib/citypay_api_client/models/capture_request.rb +27 -22
  105. data/lib/citypay_api_client/models/card.rb +33 -26
  106. data/lib/citypay_api_client/models/card_holder_account.rb +19 -20
  107. data/lib/citypay_api_client/models/card_status.rb +15 -20
  108. data/lib/citypay_api_client/models/charge_request.rb +72 -34
  109. data/lib/citypay_api_client/models/check_batch_status.rb +23 -22
  110. data/lib/citypay_api_client/models/check_batch_status_response.rb +15 -20
  111. data/lib/citypay_api_client/models/contact_details.rb +77 -42
  112. data/lib/citypay_api_client/models/decision.rb +16 -30
  113. data/lib/citypay_api_client/models/direct_post_request.rb +72 -34
  114. data/lib/citypay_api_client/models/direct_token_auth_request.rb +15 -20
  115. data/lib/citypay_api_client/models/domain_key_check_request.rb +17 -20
  116. data/lib/citypay_api_client/models/domain_key_request.rb +19 -20
  117. data/lib/citypay_api_client/models/domain_key_response.rb +25 -22
  118. data/lib/citypay_api_client/models/error.rb +27 -24
  119. data/lib/citypay_api_client/models/event_data_model.rb +15 -20
  120. data/lib/citypay_api_client/models/exists.rb +17 -20
  121. data/lib/citypay_api_client/models/external_mpi.rb +39 -24
  122. data/lib/citypay_api_client/models/list_merchants_response.rb +21 -22
  123. data/lib/citypay_api_client/models/mcc6012.rb +15 -20
  124. data/lib/citypay_api_client/models/merchant.rb +15 -20
  125. data/lib/citypay_api_client/models/merchant_batch_report_request.rb +265 -0
  126. data/lib/citypay_api_client/models/merchant_batch_report_response.rb +252 -0
  127. data/lib/citypay_api_client/models/merchant_batch_response.rb +301 -0
  128. data/lib/citypay_api_client/models/net_summary_response.rb +472 -0
  129. data/lib/citypay_api_client/models/pa_res_auth_request.rb +19 -20
  130. data/lib/citypay_api_client/models/paylink_address.rb +52 -29
  131. data/lib/citypay_api_client/models/paylink_adjustment_request.rb +25 -22
  132. data/lib/citypay_api_client/models/paylink_attachment_request.rb +19 -20
  133. data/lib/citypay_api_client/models/paylink_attachment_result.rb +19 -20
  134. data/lib/citypay_api_client/models/paylink_bill_payment_token_request.rb +17 -20
  135. data/lib/citypay_api_client/models/paylink_card_holder.rb +30 -23
  136. data/lib/citypay_api_client/models/paylink_cart.rb +15 -20
  137. data/lib/citypay_api_client/models/paylink_cart_item_model.rb +15 -20
  138. data/lib/citypay_api_client/models/paylink_config.rb +15 -20
  139. data/lib/citypay_api_client/models/paylink_custom_param.rb +29 -22
  140. data/lib/citypay_api_client/models/paylink_email_notification_path.rb +17 -20
  141. data/lib/citypay_api_client/models/paylink_error_code.rb +19 -20
  142. data/lib/citypay_api_client/models/paylink_field_guard_model.rb +16 -21
  143. data/lib/citypay_api_client/models/paylink_part_payments.rb +15 -20
  144. data/lib/citypay_api_client/models/paylink_resend_notification_request.rb +224 -0
  145. data/lib/citypay_api_client/models/paylink_sms_notification_path.rb +17 -20
  146. data/lib/citypay_api_client/models/paylink_state_event.rb +16 -21
  147. data/lib/citypay_api_client/models/paylink_token_created.rb +56 -27
  148. data/lib/citypay_api_client/models/paylink_token_request_model.rb +75 -22
  149. data/lib/citypay_api_client/models/paylink_token_status.rb +44 -21
  150. data/lib/citypay_api_client/models/paylink_token_status_change_request.rb +24 -26
  151. data/lib/citypay_api_client/models/paylink_token_status_change_response.rb +39 -22
  152. data/lib/citypay_api_client/models/paylink_ui.rb +15 -20
  153. data/lib/citypay_api_client/models/payment_intent.rb +479 -0
  154. data/lib/citypay_api_client/models/payment_intent_reference.rb +221 -0
  155. data/lib/citypay_api_client/models/ping.rb +21 -22
  156. data/lib/citypay_api_client/models/process_batch_request.rb +27 -22
  157. data/lib/citypay_api_client/models/process_batch_response.rb +17 -20
  158. data/lib/citypay_api_client/models/refund_request.rb +28 -21
  159. data/lib/citypay_api_client/models/register_card.rb +27 -22
  160. data/lib/citypay_api_client/models/remittance_data.rb +404 -0
  161. data/lib/citypay_api_client/models/remittance_report_request.rb +265 -0
  162. data/lib/citypay_api_client/models/remittance_report_response.rb +252 -0
  163. data/lib/citypay_api_client/models/remitted_client_data.rb +612 -0
  164. data/lib/citypay_api_client/models/request_challenged.rb +15 -20
  165. data/lib/citypay_api_client/models/retrieve_request.rb +23 -22
  166. data/lib/citypay_api_client/models/three_d_secure.rb +16 -21
  167. data/lib/citypay_api_client/models/tokenisation_response_model.rb +23 -24
  168. data/lib/citypay_api_client/models/void_request.rb +23 -22
  169. data/lib/citypay_api_client/version.rb +3 -3
  170. data/lib/citypay_api_client.rb +16 -3
  171. data/spec/api/reporting_api___spec.rb +99 -0
  172. data/spec/it_api_sandbox_spec.rb +5 -14
  173. data/spec/models/account_create_spec.rb +1 -2
  174. data/spec/models/account_status_spec.rb +2 -2
  175. data/spec/models/airline_advice_spec.rb +0 -2
  176. data/spec/models/airline_segment_spec.rb +0 -2
  177. data/spec/models/auth_request_spec.rb +0 -2
  178. data/spec/models/auth_response_spec.rb +75 -30
  179. data/spec/models/batch_report_request_spec.rb +0 -2
  180. data/spec/models/batch_report_response_model_spec.rb +0 -2
  181. data/spec/models/batch_spec.rb +0 -2
  182. data/spec/models/batch_transaction_report_request_spec.rb +47 -0
  183. data/spec/models/batch_transaction_report_response_spec.rb +53 -0
  184. data/spec/models/batch_transaction_result_model_spec.rb +0 -2
  185. data/spec/models/batch_transaction_spec.rb +0 -2
  186. data/spec/models/bin_lookup_spec.rb +0 -2
  187. data/spec/models/capture_request_spec.rb +0 -2
  188. data/spec/models/card_holder_account_spec.rb +0 -2
  189. data/spec/models/charge_request_spec.rb +0 -2
  190. data/spec/models/decision_spec.rb +0 -26
  191. data/spec/models/direct_post_request_spec.rb +0 -2
  192. data/spec/models/domain_key_check_request_spec.rb +0 -2
  193. data/spec/models/merchant_batch_report_request_spec.rb +65 -0
  194. data/spec/models/merchant_batch_report_response_spec.rb +53 -0
  195. data/spec/models/merchant_batch_response_spec.rb +71 -0
  196. data/spec/models/net_summary_response_spec.rb +77 -0
  197. data/spec/models/paylink_resend_notification_request_spec.rb +41 -0
  198. data/spec/models/paylink_token_request_model_spec.rb +0 -2
  199. data/spec/models/payment_intent_reference_spec.rb +35 -0
  200. data/spec/models/payment_intent_spec.rb +107 -0
  201. data/spec/models/process_batch_request_spec.rb +0 -2
  202. data/spec/models/refund_request_spec.rb +0 -2
  203. data/spec/models/register_card_spec.rb +0 -2
  204. data/spec/models/remittance_data_spec.rb +65 -0
  205. data/spec/models/remittance_report_request_spec.rb +65 -0
  206. data/spec/models/remittance_report_response_spec.rb +53 -0
  207. data/spec/models/remitted_client_data_spec.rb +113 -0
  208. data/spec/spec_helper.rb +2 -2
  209. metadata +146 -78
  210. data/docs/OperationalApi.md +0 -214
  211. data/docs/PaymentProcessingApi.md +0 -559
  212. data/spec/models/authen_required_spec.rb +0 -52
@@ -1,11 +1,11 @@
1
1
  =begin
2
2
  #CityPay Payment API
3
3
 
4
- # This CityPay API is a HTTP RESTful payment API used for direct server to server transactional processing. It provides a number of payment mechanisms including: Internet, MOTO, Continuous Authority transaction processing, 3-D Secure decision handling using RFA Secure, Authorisation, Refunding, Pre-Authorisation, Cancellation/Voids and Completion processing. The API is also capable of tokinsed payments using Card Holder Accounts. ## Compliance and Security Your application will need to adhere to PCI-DSS standards to operate safely and to meet requirements set out by Visa and MasterCard and the PCI Security Standards Council. These include * Data must be collected using TLS version 1.2 using [strong cryptography](#enabled-tls-ciphers). We will not accept calls to our API at lower grade encryption levels. We regularly scan our TLS endpoints for vulnerabilities and perform TLS assessments as part of our compliance program. * The application must not store sensitive card holder data (CHD) such as the card security code (CSC) or primary access number (PAN) * The application must not display the full card number on receipts, it is recommended to mask the PAN and show the last 4 digits. The API will return this for you for ease of receipt creation * If you are developing a website, you will be required to perform regular scans on the network where you host the application to meet your compliance obligations * You will be required to be PCI Compliant and the application must adhere to the security standard. Further information is available from [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) * The API verifies that the request is for a valid account and originates from a trusted source using the remote IP address. Our application firewalls analyse data that may be an attempt to break a large number of security common security vulnerabilities.
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
8
- OpenAPI Generator version: 6.2.1
8
+ OpenAPI Generator version: 7.2.0
9
9
 
10
10
  =end
11
11
 
@@ -92,6 +92,137 @@ 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
+
158
+ # Paylink Token Audit
159
+ # Allows for the changes to a pre-existing token.
160
+ # @param paylink_token_status_change_request [PaylinkTokenStatusChangeRequest]
161
+ # @param [Hash] opts the optional parameters
162
+ # @return [PaylinkTokenStatusChangeResponse]
163
+ def token_changes_request(paylink_token_status_change_request, opts = {})
164
+ data, _status_code, _headers = token_changes_request_with_http_info(paylink_token_status_change_request, opts)
165
+ data
166
+ end
167
+
168
+ # Paylink Token Audit
169
+ # Allows for the changes to a pre-existing token.
170
+ # @param paylink_token_status_change_request [PaylinkTokenStatusChangeRequest]
171
+ # @param [Hash] opts the optional parameters
172
+ # @return [Array<(PaylinkTokenStatusChangeResponse, Integer, Hash)>] PaylinkTokenStatusChangeResponse data, response status code and response headers
173
+ def token_changes_request_with_http_info(paylink_token_status_change_request, opts = {})
174
+ if @api_client.config.debugging
175
+ @api_client.config.logger.debug 'Calling API: PaylinkApi.token_changes_request ...'
176
+ end
177
+ # verify the required parameter 'paylink_token_status_change_request' is set
178
+ if @api_client.config.client_side_validation && paylink_token_status_change_request.nil?
179
+ fail ArgumentError, "Missing the required parameter 'paylink_token_status_change_request' when calling PaylinkApi.token_changes_request"
180
+ end
181
+ # resource path
182
+ local_var_path = '/paylink/token/changes'
183
+
184
+ # query parameters
185
+ query_params = opts[:query_params] || {}
186
+
187
+ # header parameters
188
+ header_params = opts[:header_params] || {}
189
+ # HTTP header 'Accept' (if needed)
190
+ header_params['Accept'] = @api_client.select_header_accept(['application/json', 'text/xml'])
191
+ # HTTP header 'Content-Type'
192
+ content_type = @api_client.select_header_content_type(['application/json', 'text/xml'])
193
+ if !content_type.nil?
194
+ header_params['Content-Type'] = content_type
195
+ end
196
+
197
+ # form parameters
198
+ form_params = opts[:form_params] || {}
199
+
200
+ # http body (model)
201
+ post_body = opts[:debug_body] || @api_client.object_to_http_body(paylink_token_status_change_request)
202
+
203
+ # return_type
204
+ return_type = opts[:debug_return_type] || 'PaylinkTokenStatusChangeResponse'
205
+
206
+ # auth_names
207
+ auth_names = opts[:debug_auth_names] || ['cp-api-key']
208
+
209
+ new_options = opts.merge(
210
+ :operation => :"PaylinkApi.token_changes_request",
211
+ :header_params => header_params,
212
+ :query_params => query_params,
213
+ :form_params => form_params,
214
+ :body => post_body,
215
+ :auth_names => auth_names,
216
+ :return_type => return_type
217
+ )
218
+
219
+ data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
220
+ if @api_client.config.debugging
221
+ @api_client.config.logger.debug "API called: PaylinkApi#token_changes_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
222
+ end
223
+ return data, status_code, headers
224
+ end
225
+
95
226
  # Close Paylink Token
96
227
  # Marks a Paylink Token as closed. This closes the Token for any future action and the Token will not appear in any status request calls.
97
228
  # @param token [String] The token returned by the create token process.
@@ -156,7 +287,7 @@ module CityPayApiClient
156
287
  end
157
288
 
158
289
  # Create Bill Payment Paylink Token
159
- # CityPay Paylink supports invoice and bill payment services by allowing merchants to raise an invoice in their systems and associate the invoice with a Paylink checkout token. CityPay will co-ordinate the checkout flow in relationship with your customer. Our bill payment solution may be used to streamline the payment flow with cardholders to allow your invoice to be paid promptly and via multiple payment channels such as Card Payment, Apple Pay or Google Pay. The bill payment service allows 1. setting up notification paths to an end customer, such as SMS or Email 2. enabling attachments to be included with Paylink tokens 3. produce chaser notifications for unpaid invoices 4. provide callbacks for notification of the payment of an invoice 5. support part payments against an invoice 6. support of field guards to protect the payment screen 7. support of status reporting on tokens 8. URL short codes for SMS notifications <img src=\"../images/merchant-BPS-workflow.png\" alt=\"Paylink BPSv2 Overview\" width=\"50%\"/> ### Notification Paths Notification paths can be provided which identify the channels for communication of the invoice availability. Up to 3 notification paths may be provided per request. Each notification uses a template to generate the body of the message. This allows for variable text to be sent out and customised for each call. SMS messages use URL Short Codes (USC) as a payment link to the invoice payment page. This allows for a standard payment URL to be shortened for optimised usage in SMS. For instance a URL of `https://checkout.citypay.com/PL1234/s348yb8yna4a48n2f8nq2f3msgyng-psn348ynaw8ynaw/en` becomes `citypay.com/Za48na3x`. Each USC is unique however it is a requirement that each USC generated is protected with Field Guards to ensure that sensitive data (such as customer contact details and GDPR) is protected. To send a notification path, append a `notification-path` property to the request. ```json { \"sms_notification_path\": { \"to\": \"+441534884000\" }, \"email_notification_path\": { \"to\": [\"help-desk@citypay.com\"], \"cc\": [\"third-party@citypay.com\"], \"reply\": [\"help@my-company.com\"] } } ``` Notification paths trigger a number of events which are stored as part of the timeline of events of a Paylink token - `BillPaymentSmsNotificationQueued` - identifies when an SMS notification has been queued for delivery - `BillPaymentSmsNotificationSent` - identifies when an SMS notification has been sent to the upstream network - `BillPaymentSmsNotificationDelivered` - identifies when an SMS notification has been delivered as notified by the upstream network - `BillPaymentSmsNotificationUndelivered` - identifies when an SMS notification has undelivered notification is provided by the upstream network - `BillPaymentSmsNotificationFailure` - identifies when an SMS notification has failed - `BillPaymentEmailNotificationQueued` - identifies when an email notification has been queued for delivery - `BillPaymentEmailNotificationSent` - identifies when an email notification has been accepted by our SMS forwarder - `BillPaymentEmailNotificationFailure` - identifies when an email notification has failed delivery #### SMS Notification Path SMS originated from a CityPay pool of numbers and by default only sends to country codes where the service is registered. SMSs may contain a From field which is configured as part of you onboarding and have a name associated to identify the service origin. For example if your business is titled `Health Surgery Ltd` the SMS may be sent to originate from `Health Surgery`. SMS is also configured for a \"polite mode\". This mode ensures that SMSs aren't sent in the middle of the night when backend services ordinarily run. SMSs will be queued until the time range is deemed as polite. Normally this is between 8am and 9pm. | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string | Reserved | The phone number in [E.164](https://en.wikipedia.org/wiki/E.164) format to send the message to. | #### Email Notification Paths | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string[] | Required | An array of email addresses to be used for delivery. A maximum of 5 addresses can be added. | | cc | string[] | Required | An array of email addresses to be used for cc delivery. A maximum of 5 addresses can be added. | | bcc | string[] | Required | An array of email addresses to be used for bcc delivery. A maximum of 5 addresses can be added. | | reply_to | string[] | Required | An array of email addresses to be used for the Reply-To header of an email. | ### Field Guards To ensure that invoices are paid by the intended recipient, Paylink supports the addition of Field Guards. A Field Guard is an intended field which is to be used as a form of guarded authentication. More than 1 field can be requested. <img src=\"../images/paylink-field-guards.png\" alt=\"Paylink Field Guards\" width=\"50%\"/> To determine the source value of the field, each field name is searched in the order of - identifier - cardholder data such as name - custom parameters - pass through data If no field values are found, the token request returns a D041 validation error. #### Authentication and Validation When values are entered by the user, resultant comparisons are performed by 1. Transliteration of both the source value and entered value. For example, names with accents (e.g. é will become e) 2. Only Alphanumeric values are retained any whitespace or special characters are ignored 3. Case is ignored Should all values match, the user is authenticated and can continue to the payment form rendered by the Paylink server. On successful login, an event will be added to include that the access guard validated access. #### Access-Key To ensure that a user does not need to re-enter these values multiple times, a cookie is pushed to the user’s browser with an access-key digest value. This value will be presented to the server on each refresh therefore allowing the guard to accept the call. Each value is uniquely stored per merchant account and cannot be shared cross merchant. The lifetime of the cookie is set to 24 hours. #### Brute Force Prevention To prevent multiple calls hitting the server, attempting a brute force attack, the login process 1. is fronted by a contemporary web application firewall 2. creates an event for each token when access was denied 3. should the number of failed events breach more than 5 in 30 minutes, the token is locked for an hour 4. should the number of events breach more than 20 the token is fully locked ### Attachments Attachments can be included in the request in 2 ways 1. Via a data element direct in the request 2. Via a URL upload to a provided pre-signed URL The decision of which option is dependent on the size of the attachments. Should the attachment size be greater than 32kb a URL upload is required. Small attachments can be included in the JSON request. This is to prevent our web firewall from blocking your request and to also ensure efficiency of larger file uploads. There is a maximum of 3 attachments that can be added to a request. ```json [{ \"filename\": \"invoice1.pdf\", \"mime-type\": \"application/pdf\" },{ \"filename\": \"invoice2.pdf\", \"data\": \"b4sE64Enc0dEd...=\", \"mime-type\": \"application/pdf\" }] ``` | Field | Type | Usage | Description | |-----------|--------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------| | filename | string | Required | The name of the attachment normally taken from the filename. You should not include the filename path as appropriate | | data | string | Optional | base64 encoding of the file if less than 32kb in size | | mime-type | string | Required | The mime type of the attachment as defined in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html). Currently only `application/pdf` is supported | #### Attachment Result A result of an attachment specifies whether the attachment was successfully added or whether a further upload is requried | Field | Type | Usage | Description | |--------|--------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------| | result | string | Required | `OK` should the file have uploaded or `UPLOAD` if the file is required to be uploaded. | | name | string | Required | The filename that was specified in the upload process | | url | string | Optional | Should an upload be required, this URL is available for an upload to be issued. The URL is only available for uploads for 24 hours from creation. |
290
+ # CityPay Paylink supports invoice and bill payment services by allowing merchants to raise an invoice in their systems and associate the invoice with a Paylink checkout token. CityPay will co-ordinate the checkout flow in relationship with your customer. Our bill payment solution may be used to streamline the payment flow with cardholders to allow your invoice to be paid promptly and via multiple payment channels such as Card Payment, Apple Pay or Google Pay. The bill payment service allows 1. setting up notification paths to an end customer, such as SMS or Email 2. enabling attachments to be included with Paylink tokens 3. produce chaser notifications for unpaid invoices 4. provide callbacks for notification of the payment of an invoice 5. support part payments against an invoice 6. support of field guards to protect the payment screen 7. support of status reporting on tokens 8. URL short codes for SMS notifications <img src=\"images/merchant-BPS-workflow.png\" alt=\"Paylink BPSv2 Overview\" width=\"50%\"/> ### Notification Paths Notification paths can be provided which identify the channels for communication of the invoice availability. Up to 3 notification paths may be provided per request. Each notification uses a template to generate the body of the message. This allows for variable text to be sent out and customised for each call. SMS messages use URL Short Codes (USC) as a payment link to the invoice payment page. This allows for a standard payment URL to be shortened for optimised usage in SMS. For instance a URL of `https://checkout.citypay.com/PL1234/s348yb8yna4a48n2f8nq2f3msgyng-psn348ynaw8ynaw/en` becomes `citypay.com/Za48na3x`. Each USC is unique however it is a requirement that each USC generated is protected with Field Guards to ensure that sensitive data (such as customer contact details and GDPR) is protected. To send a notification path, append a `notification-path` property to the request. ```json { \"sms_notification_path\": { \"to\": \"+441534884000\" }, \"email_notification_path\": { \"to\": [\"help-desk@citypay.com\"], \"cc\": [\"third-party@citypay.com\"], \"reply\": [\"help@my-company.com\"] } } ``` Notification paths trigger a number of events which are stored as part of the timeline of events of a Paylink token - `BillPaymentSmsNotificationQueued` - identifies when an SMS notification has been queued for delivery - `BillPaymentSmsNotificationSent` - identifies when an SMS notification has been sent to the upstream network - `BillPaymentSmsNotificationDelivered` - identifies when an SMS notification has been delivered as notified by the upstream network - `BillPaymentSmsNotificationUndelivered` - identifies when an SMS notification has undelivered notification is provided by the upstream network - `BillPaymentSmsNotificationFailure` - identifies when an SMS notification has failed - `BillPaymentEmailNotificationQueued` - identifies when an email notification has been queued for delivery - `BillPaymentEmailNotificationSent` - identifies when an email notification has been accepted by our SMS forwarder - `BillPaymentEmailNotificationFailure` - identifies when an email notification has failed delivery #### SMS Notification Path SMS originated from a CityPay pool of numbers and by default only sends to country codes where the service is registered. SMSs may contain a From field which is configured as part of you onboarding and have a name associated to identify the service origin. For example if your business is titled `Health Surgery Ltd` the SMS may be sent to originate from `Health Surgery`. SMS is also configured for a \"polite mode\". This mode ensures that SMSs aren't sent in the middle of the night when backend services ordinarily run. SMSs will be queued until the time range is deemed as polite. Normally this is between 8am and 9pm. | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string | Reserved | The phone number in [E.164](https://en.wikipedia.org/wiki/E.164) format to send the message to. | #### Email Notification Paths | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string[] | Required | An array of email addresses to be used for delivery. A maximum of 5 addresses can be added. | | cc | string[] | Required | An array of email addresses to be used for cc delivery. A maximum of 5 addresses can be added. | | bcc | string[] | Required | An array of email addresses to be used for bcc delivery. A maximum of 5 addresses can be added. | | reply_to | string[] | Required | An array of email addresses to be used for the Reply-To header of an email. | ### Field Guards To ensure that invoices are paid by the intended recipient, Paylink supports the addition of Field Guards. A Field Guard is an intended field which is to be used as a form of guarded authentication. More than 1 field can be requested. <img src=\"images/paylink-field-guards.png\" alt=\"Paylink Field Guards\" width=\"50%\"/> To determine the source value of the field, each field name is searched in the order of - identifier - cardholder data such as name - custom parameters - pass through data If no field values are found, the token request returns a D041 validation error. #### Authentication and Validation When values are entered by the user, resultant comparisons are performed by 1. Transliteration of both the source value and entered value. For example, names with accents (e.g. é will become e) 2. Only Alphanumeric values are retained any whitespace or special characters are ignored 3. Case is ignored Should all values match, the user is authenticated and can continue to the payment form rendered by the Paylink server. On successful login, an event will be added to include that the access guard validated access. #### Access-Key To ensure that a user does not need to re-enter these values multiple times, a cookie is pushed to the user’s browser with an access-key digest value. This value will be presented to the server on each refresh therefore allowing the guard to accept the call. Each value is uniquely stored per merchant account and cannot be shared cross merchant. The lifetime of the cookie is set to 24 hours. #### Brute Force Prevention To prevent multiple calls hitting the server, attempting a brute force attack, the login process 1. is fronted by a contemporary web application firewall 2. creates an event for each token when access was denied 3. should the number of failed events breach more than 5 in 30 minutes, the token is locked for an hour 4. should the number of events breach more than 20 the token is fully locked ### Attachments Attachments can be included in the request in 2 ways 1. Via a data element direct in the request 2. Via a URL upload to a provided pre-signed URL The decision of which option is dependent on the size of the attachments. Should the attachment size be greater than 32kb a URL upload is required. Small attachments can be included in the JSON request. This is to prevent our web firewall from blocking your request and to also ensure efficiency of larger file uploads. There is a maximum of 3 attachments that can be added to a request. ```json [{ \"filename\": \"invoice1.pdf\", \"mime-type\": \"application/pdf\" },{ \"filename\": \"invoice2.pdf\", \"data\": \"b4sE64Enc0dEd...=\", \"mime-type\": \"application/pdf\" }] ``` | Field | Type | Usage | Description | |-----------|--------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------| | filename | string | Required | The name of the attachment normally taken from the filename. You should not include the filename path as appropriate | | data | string | Optional | base64 encoding of the file if less than 32kb in size | | mime-type | string | Required | The mime type of the attachment as defined in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html). Currently only `application/pdf` is supported | #### Attachment Result A result of an attachment specifies whether the attachment was successfully added or whether a further upload is requried | Field | Type | Usage | Description | |--------|--------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------| | result | string | Required | `OK` should the file have uploaded or `UPLOAD` if the file is required to be uploaded. | | name | string | Required | The filename that was specified in the upload process | | url | string | Optional | Should an upload be required, this URL is available for an upload to be issued. The URL is only available for uploads for 24 hours from creation. |
160
291
  # @param paylink_bill_payment_token_request [PaylinkBillPaymentTokenRequest]
161
292
  # @param [Hash] opts the optional parameters
162
293
  # @return [PaylinkTokenCreated]
@@ -166,7 +297,7 @@ module CityPayApiClient
166
297
  end
167
298
 
168
299
  # Create Bill Payment Paylink Token
169
- # CityPay Paylink supports invoice and bill payment services by allowing merchants to raise an invoice in their systems and associate the invoice with a Paylink checkout token. CityPay will co-ordinate the checkout flow in relationship with your customer. Our bill payment solution may be used to streamline the payment flow with cardholders to allow your invoice to be paid promptly and via multiple payment channels such as Card Payment, Apple Pay or Google Pay. The bill payment service allows 1. setting up notification paths to an end customer, such as SMS or Email 2. enabling attachments to be included with Paylink tokens 3. produce chaser notifications for unpaid invoices 4. provide callbacks for notification of the payment of an invoice 5. support part payments against an invoice 6. support of field guards to protect the payment screen 7. support of status reporting on tokens 8. URL short codes for SMS notifications &lt;img src&#x3D;\&quot;../images/merchant-BPS-workflow.png\&quot; alt&#x3D;\&quot;Paylink BPSv2 Overview\&quot; width&#x3D;\&quot;50%\&quot;/&gt; ### Notification Paths Notification paths can be provided which identify the channels for communication of the invoice availability. Up to 3 notification paths may be provided per request. Each notification uses a template to generate the body of the message. This allows for variable text to be sent out and customised for each call. SMS messages use URL Short Codes (USC) as a payment link to the invoice payment page. This allows for a standard payment URL to be shortened for optimised usage in SMS. For instance a URL of &#x60;https://checkout.citypay.com/PL1234/s348yb8yna4a48n2f8nq2f3msgyng-psn348ynaw8ynaw/en&#x60; becomes &#x60;citypay.com/Za48na3x&#x60;. Each USC is unique however it is a requirement that each USC generated is protected with Field Guards to ensure that sensitive data (such as customer contact details and GDPR) is protected. To send a notification path, append a &#x60;notification-path&#x60; property to the request. &#x60;&#x60;&#x60;json { \&quot;sms_notification_path\&quot;: { \&quot;to\&quot;: \&quot;+441534884000\&quot; }, \&quot;email_notification_path\&quot;: { \&quot;to\&quot;: [\&quot;help-desk@citypay.com\&quot;], \&quot;cc\&quot;: [\&quot;third-party@citypay.com\&quot;], \&quot;reply\&quot;: [\&quot;help@my-company.com\&quot;] } } &#x60;&#x60;&#x60; Notification paths trigger a number of events which are stored as part of the timeline of events of a Paylink token - &#x60;BillPaymentSmsNotificationQueued&#x60; - identifies when an SMS notification has been queued for delivery - &#x60;BillPaymentSmsNotificationSent&#x60; - identifies when an SMS notification has been sent to the upstream network - &#x60;BillPaymentSmsNotificationDelivered&#x60; - identifies when an SMS notification has been delivered as notified by the upstream network - &#x60;BillPaymentSmsNotificationUndelivered&#x60; - identifies when an SMS notification has undelivered notification is provided by the upstream network - &#x60;BillPaymentSmsNotificationFailure&#x60; - identifies when an SMS notification has failed - &#x60;BillPaymentEmailNotificationQueued&#x60; - identifies when an email notification has been queued for delivery - &#x60;BillPaymentEmailNotificationSent&#x60; - identifies when an email notification has been accepted by our SMS forwarder - &#x60;BillPaymentEmailNotificationFailure&#x60; - identifies when an email notification has failed delivery #### SMS Notification Path SMS originated from a CityPay pool of numbers and by default only sends to country codes where the service is registered. SMSs may contain a From field which is configured as part of you onboarding and have a name associated to identify the service origin. For example if your business is titled &#x60;Health Surgery Ltd&#x60; the SMS may be sent to originate from &#x60;Health Surgery&#x60;. SMS is also configured for a \&quot;polite mode\&quot;. This mode ensures that SMSs aren&#39;t sent in the middle of the night when backend services ordinarily run. SMSs will be queued until the time range is deemed as polite. Normally this is between 8am and 9pm. | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string | Reserved | The phone number in [E.164](https://en.wikipedia.org/wiki/E.164) format to send the message to. | #### Email Notification Paths | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string[] | Required | An array of email addresses to be used for delivery. A maximum of 5 addresses can be added. | | cc | string[] | Required | An array of email addresses to be used for cc delivery. A maximum of 5 addresses can be added. | | bcc | string[] | Required | An array of email addresses to be used for bcc delivery. A maximum of 5 addresses can be added. | | reply_to | string[] | Required | An array of email addresses to be used for the Reply-To header of an email. | ### Field Guards To ensure that invoices are paid by the intended recipient, Paylink supports the addition of Field Guards. A Field Guard is an intended field which is to be used as a form of guarded authentication. More than 1 field can be requested. &lt;img src&#x3D;\&quot;../images/paylink-field-guards.png\&quot; alt&#x3D;\&quot;Paylink Field Guards\&quot; width&#x3D;\&quot;50%\&quot;/&gt; To determine the source value of the field, each field name is searched in the order of - identifier - cardholder data such as name - custom parameters - pass through data If no field values are found, the token request returns a D041 validation error. #### Authentication and Validation When values are entered by the user, resultant comparisons are performed by 1. Transliteration of both the source value and entered value. For example, names with accents (e.g. é will become e) 2. Only Alphanumeric values are retained any whitespace or special characters are ignored 3. Case is ignored Should all values match, the user is authenticated and can continue to the payment form rendered by the Paylink server. On successful login, an event will be added to include that the access guard validated access. #### Access-Key To ensure that a user does not need to re-enter these values multiple times, a cookie is pushed to the user’s browser with an access-key digest value. This value will be presented to the server on each refresh therefore allowing the guard to accept the call. Each value is uniquely stored per merchant account and cannot be shared cross merchant. The lifetime of the cookie is set to 24 hours. #### Brute Force Prevention To prevent multiple calls hitting the server, attempting a brute force attack, the login process 1. is fronted by a contemporary web application firewall 2. creates an event for each token when access was denied 3. should the number of failed events breach more than 5 in 30 minutes, the token is locked for an hour 4. should the number of events breach more than 20 the token is fully locked ### Attachments Attachments can be included in the request in 2 ways 1. Via a data element direct in the request 2. Via a URL upload to a provided pre-signed URL The decision of which option is dependent on the size of the attachments. Should the attachment size be greater than 32kb a URL upload is required. Small attachments can be included in the JSON request. This is to prevent our web firewall from blocking your request and to also ensure efficiency of larger file uploads. There is a maximum of 3 attachments that can be added to a request. &#x60;&#x60;&#x60;json [{ \&quot;filename\&quot;: \&quot;invoice1.pdf\&quot;, \&quot;mime-type\&quot;: \&quot;application/pdf\&quot; },{ \&quot;filename\&quot;: \&quot;invoice2.pdf\&quot;, \&quot;data\&quot;: \&quot;b4sE64Enc0dEd...&#x3D;\&quot;, \&quot;mime-type\&quot;: \&quot;application/pdf\&quot; }] &#x60;&#x60;&#x60; | Field | Type | Usage | Description | |-----------|--------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------| | filename | string | Required | The name of the attachment normally taken from the filename. You should not include the filename path as appropriate | | data | string | Optional | base64 encoding of the file if less than 32kb in size | | mime-type | string | Required | The mime type of the attachment as defined in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html). Currently only &#x60;application/pdf&#x60; is supported | #### Attachment Result A result of an attachment specifies whether the attachment was successfully added or whether a further upload is requried | Field | Type | Usage | Description | |--------|--------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------| | result | string | Required | &#x60;OK&#x60; should the file have uploaded or &#x60;UPLOAD&#x60; if the file is required to be uploaded. | | name | string | Required | The filename that was specified in the upload process | | url | string | Optional | Should an upload be required, this URL is available for an upload to be issued. The URL is only available for uploads for 24 hours from creation. |
300
+ # CityPay Paylink supports invoice and bill payment services by allowing merchants to raise an invoice in their systems and associate the invoice with a Paylink checkout token. CityPay will co-ordinate the checkout flow in relationship with your customer. Our bill payment solution may be used to streamline the payment flow with cardholders to allow your invoice to be paid promptly and via multiple payment channels such as Card Payment, Apple Pay or Google Pay. The bill payment service allows 1. setting up notification paths to an end customer, such as SMS or Email 2. enabling attachments to be included with Paylink tokens 3. produce chaser notifications for unpaid invoices 4. provide callbacks for notification of the payment of an invoice 5. support part payments against an invoice 6. support of field guards to protect the payment screen 7. support of status reporting on tokens 8. URL short codes for SMS notifications &lt;img src&#x3D;\&quot;images/merchant-BPS-workflow.png\&quot; alt&#x3D;\&quot;Paylink BPSv2 Overview\&quot; width&#x3D;\&quot;50%\&quot;/&gt; ### Notification Paths Notification paths can be provided which identify the channels for communication of the invoice availability. Up to 3 notification paths may be provided per request. Each notification uses a template to generate the body of the message. This allows for variable text to be sent out and customised for each call. SMS messages use URL Short Codes (USC) as a payment link to the invoice payment page. This allows for a standard payment URL to be shortened for optimised usage in SMS. For instance a URL of &#x60;https://checkout.citypay.com/PL1234/s348yb8yna4a48n2f8nq2f3msgyng-psn348ynaw8ynaw/en&#x60; becomes &#x60;citypay.com/Za48na3x&#x60;. Each USC is unique however it is a requirement that each USC generated is protected with Field Guards to ensure that sensitive data (such as customer contact details and GDPR) is protected. To send a notification path, append a &#x60;notification-path&#x60; property to the request. &#x60;&#x60;&#x60;json { \&quot;sms_notification_path\&quot;: { \&quot;to\&quot;: \&quot;+441534884000\&quot; }, \&quot;email_notification_path\&quot;: { \&quot;to\&quot;: [\&quot;help-desk@citypay.com\&quot;], \&quot;cc\&quot;: [\&quot;third-party@citypay.com\&quot;], \&quot;reply\&quot;: [\&quot;help@my-company.com\&quot;] } } &#x60;&#x60;&#x60; Notification paths trigger a number of events which are stored as part of the timeline of events of a Paylink token - &#x60;BillPaymentSmsNotificationQueued&#x60; - identifies when an SMS notification has been queued for delivery - &#x60;BillPaymentSmsNotificationSent&#x60; - identifies when an SMS notification has been sent to the upstream network - &#x60;BillPaymentSmsNotificationDelivered&#x60; - identifies when an SMS notification has been delivered as notified by the upstream network - &#x60;BillPaymentSmsNotificationUndelivered&#x60; - identifies when an SMS notification has undelivered notification is provided by the upstream network - &#x60;BillPaymentSmsNotificationFailure&#x60; - identifies when an SMS notification has failed - &#x60;BillPaymentEmailNotificationQueued&#x60; - identifies when an email notification has been queued for delivery - &#x60;BillPaymentEmailNotificationSent&#x60; - identifies when an email notification has been accepted by our SMS forwarder - &#x60;BillPaymentEmailNotificationFailure&#x60; - identifies when an email notification has failed delivery #### SMS Notification Path SMS originated from a CityPay pool of numbers and by default only sends to country codes where the service is registered. SMSs may contain a From field which is configured as part of you onboarding and have a name associated to identify the service origin. For example if your business is titled &#x60;Health Surgery Ltd&#x60; the SMS may be sent to originate from &#x60;Health Surgery&#x60;. SMS is also configured for a \&quot;polite mode\&quot;. This mode ensures that SMSs aren&#39;t sent in the middle of the night when backend services ordinarily run. SMSs will be queued until the time range is deemed as polite. Normally this is between 8am and 9pm. | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string | Reserved | The phone number in [E.164](https://en.wikipedia.org/wiki/E.164) format to send the message to. | #### Email Notification Paths | Field | Type | Usage | Description | |----------|----------|----------|-------------------------------------------------------------------------------------------------| | template | string | Reserved | An optional template name to use a template other than the default. | | to | string[] | Required | An array of email addresses to be used for delivery. A maximum of 5 addresses can be added. | | cc | string[] | Required | An array of email addresses to be used for cc delivery. A maximum of 5 addresses can be added. | | bcc | string[] | Required | An array of email addresses to be used for bcc delivery. A maximum of 5 addresses can be added. | | reply_to | string[] | Required | An array of email addresses to be used for the Reply-To header of an email. | ### Field Guards To ensure that invoices are paid by the intended recipient, Paylink supports the addition of Field Guards. A Field Guard is an intended field which is to be used as a form of guarded authentication. More than 1 field can be requested. &lt;img src&#x3D;\&quot;images/paylink-field-guards.png\&quot; alt&#x3D;\&quot;Paylink Field Guards\&quot; width&#x3D;\&quot;50%\&quot;/&gt; To determine the source value of the field, each field name is searched in the order of - identifier - cardholder data such as name - custom parameters - pass through data If no field values are found, the token request returns a D041 validation error. #### Authentication and Validation When values are entered by the user, resultant comparisons are performed by 1. Transliteration of both the source value and entered value. For example, names with accents (e.g. é will become e) 2. Only Alphanumeric values are retained any whitespace or special characters are ignored 3. Case is ignored Should all values match, the user is authenticated and can continue to the payment form rendered by the Paylink server. On successful login, an event will be added to include that the access guard validated access. #### Access-Key To ensure that a user does not need to re-enter these values multiple times, a cookie is pushed to the user’s browser with an access-key digest value. This value will be presented to the server on each refresh therefore allowing the guard to accept the call. Each value is uniquely stored per merchant account and cannot be shared cross merchant. The lifetime of the cookie is set to 24 hours. #### Brute Force Prevention To prevent multiple calls hitting the server, attempting a brute force attack, the login process 1. is fronted by a contemporary web application firewall 2. creates an event for each token when access was denied 3. should the number of failed events breach more than 5 in 30 minutes, the token is locked for an hour 4. should the number of events breach more than 20 the token is fully locked ### Attachments Attachments can be included in the request in 2 ways 1. Via a data element direct in the request 2. Via a URL upload to a provided pre-signed URL The decision of which option is dependent on the size of the attachments. Should the attachment size be greater than 32kb a URL upload is required. Small attachments can be included in the JSON request. This is to prevent our web firewall from blocking your request and to also ensure efficiency of larger file uploads. There is a maximum of 3 attachments that can be added to a request. &#x60;&#x60;&#x60;json [{ \&quot;filename\&quot;: \&quot;invoice1.pdf\&quot;, \&quot;mime-type\&quot;: \&quot;application/pdf\&quot; },{ \&quot;filename\&quot;: \&quot;invoice2.pdf\&quot;, \&quot;data\&quot;: \&quot;b4sE64Enc0dEd...&#x3D;\&quot;, \&quot;mime-type\&quot;: \&quot;application/pdf\&quot; }] &#x60;&#x60;&#x60; | Field | Type | Usage | Description | |-----------|--------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------| | filename | string | Required | The name of the attachment normally taken from the filename. You should not include the filename path as appropriate | | data | string | Optional | base64 encoding of the file if less than 32kb in size | | mime-type | string | Required | The mime type of the attachment as defined in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html). Currently only &#x60;application/pdf&#x60; is supported | #### Attachment Result A result of an attachment specifies whether the attachment was successfully added or whether a further upload is requried | Field | Type | Usage | Description | |--------|--------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------| | result | string | Required | &#x60;OK&#x60; should the file have uploaded or &#x60;UPLOAD&#x60; if the file is required to be uploaded. | | name | string | Required | The filename that was specified in the upload process | | url | string | Optional | Should an upload be required, this URL is available for an upload to be issued. The URL is only available for uploads for 24 hours from creation. |
170
301
  # @param paylink_bill_payment_token_request [PaylinkBillPaymentTokenRequest]
171
302
  # @param [Hash] opts the optional parameters
172
303
  # @return [Array<(PaylinkTokenCreated, Integer, Hash)>] PaylinkTokenCreated data, response status code and response headers
@@ -355,7 +486,7 @@ module CityPayApiClient
355
486
  end
356
487
 
357
488
  # Reconcile Paylink Token
358
- # Marks a Paylink Token as reconciled when reconcilation is performed on the merchant's side.
489
+ # Marks a Paylink Token as reconciled when reconciliation is performed on the merchant's side.
359
490
  # @param token [String] The token returned by the create token process.
360
491
  # @param [Hash] opts the optional parameters
361
492
  # @return [Acknowledgement]
@@ -365,7 +496,7 @@ module CityPayApiClient
365
496
  end
366
497
 
367
498
  # Reconcile Paylink Token
368
- # Marks a Paylink Token as reconciled when reconcilation is performed on the merchant&#39;s side.
499
+ # Marks a Paylink Token as reconciled when reconciliation is performed on the merchant&#39;s side.
369
500
  # @param token [String] The token returned by the create token process.
370
501
  # @param [Hash] opts the optional parameters
371
502
  # @return [Array<(Acknowledgement, Integer, Hash)>] Acknowledgement data, response status code and response headers
@@ -480,31 +611,37 @@ module CityPayApiClient
480
611
  return data, status_code, headers
481
612
  end
482
613
 
483
- # Paylink Token Audit
484
- # Obtains any changes on Paylink Tokens since a given date and time. This allows for a merchant to regularly check on activity over a collection of Paylink Tokens and to check on any events that may have occurred. If a Token is `Closed` it is not considered. Only statuses that have been appended since the given date and time is returned.
485
- # @param paylink_token_status_change_request [PaylinkTokenStatusChangeRequest]
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]
486
618
  # @param [Hash] opts the optional parameters
487
- # @return [PaylinkTokenStatusChangeResponse]
488
- def token_status_changes_request(paylink_token_status_change_request, opts = {})
489
- data, _status_code, _headers = token_status_changes_request_with_http_info(paylink_token_status_change_request, opts)
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)
490
622
  data
491
623
  end
492
624
 
493
- # Paylink Token Audit
494
- # Obtains any changes on Paylink Tokens since a given date and time. This allows for a merchant to regularly check on activity over a collection of Paylink Tokens and to check on any events that may have occurred. If a Token is &#x60;Closed&#x60; it is not considered. Only statuses that have been appended since the given date and time is returned.
495
- # @param paylink_token_status_change_request [PaylinkTokenStatusChangeRequest]
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]
496
629
  # @param [Hash] opts the optional parameters
497
- # @return [Array<(PaylinkTokenStatusChangeResponse, Integer, Hash)>] PaylinkTokenStatusChangeResponse data, response status code and response headers
498
- def token_status_changes_request_with_http_info(paylink_token_status_change_request, opts = {})
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 = {})
499
632
  if @api_client.config.debugging
500
- @api_client.config.logger.debug 'Calling API: PaylinkApi.token_status_changes_request ...'
633
+ @api_client.config.logger.debug 'Calling API: PaylinkApi.token_resend_notification_request ...'
501
634
  end
502
- # verify the required parameter 'paylink_token_status_change_request' is set
503
- if @api_client.config.client_side_validation && paylink_token_status_change_request.nil?
504
- fail ArgumentError, "Missing the required parameter 'paylink_token_status_change_request' when calling PaylinkApi.token_status_changes_request"
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"
505
642
  end
506
643
  # resource path
507
- local_var_path = '/paylink/token/changes'
644
+ local_var_path = '/paylink/{token}/resend-notification'.sub('{' + 'token' + '}', CGI.escape(token.to_s))
508
645
 
509
646
  # query parameters
510
647
  query_params = opts[:query_params] || {}
@@ -523,16 +660,16 @@ module CityPayApiClient
523
660
  form_params = opts[:form_params] || {}
524
661
 
525
662
  # http body (model)
526
- post_body = opts[:debug_body] || @api_client.object_to_http_body(paylink_token_status_change_request)
663
+ post_body = opts[:debug_body] || @api_client.object_to_http_body(paylink_resend_notification_request)
527
664
 
528
665
  # return_type
529
- return_type = opts[:debug_return_type] || 'PaylinkTokenStatusChangeResponse'
666
+ return_type = opts[:debug_return_type] || 'Acknowledgement'
530
667
 
531
668
  # auth_names
532
669
  auth_names = opts[:debug_auth_names] || ['cp-api-key']
533
670
 
534
671
  new_options = opts.merge(
535
- :operation => :"PaylinkApi.token_status_changes_request",
672
+ :operation => :"PaylinkApi.token_resend_notification_request",
536
673
  :header_params => header_params,
537
674
  :query_params => query_params,
538
675
  :form_params => form_params,
@@ -543,7 +680,7 @@ module CityPayApiClient
543
680
 
544
681
  data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
545
682
  if @api_client.config.debugging
546
- @api_client.config.logger.debug "API called: PaylinkApi#token_status_changes_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
683
+ @api_client.config.logger.debug "API called: PaylinkApi#token_resend_notification_request\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
547
684
  end
548
685
  return data, status_code, headers
549
686
  end