--- title: "Payment cancellation request" method: DELETE path: "/v1/{payment-service}/{payment-product}/{paymentId}" tags: ["Payment Initiation Service (PIS)"] --- # Payment cancellation request `DELETE /v1/{payment-service}/{payment-product}/{paymentId}` This method initiates the cancellation of a payment. Depending on the payment-service, the payment-product and the ASPSP's implementation, this TPP call might be sufficient to cancel a payment. If an authorisation of the payment cancellation is mandated by the ASPSP, a corresponding hyperlink will be contained in the response message. Cancels the addressed payment with resource identification paymentId if applicable to the payment-service, payment-product and received in product related timelines (e.g. before end of business day for scheduled payments of the last business day before the scheduled execution day). The response to this DELETE command will tell the TPP whether the * access method was rejected, * access method was successful, or * access method is generally applicable, but further authorisation processes are needed. ## Path parameters - `payment-service` 'payments' | 'bulk-payments' | 'periodic-payments', required - `payment-product` 'domestic-swiss-credit-transfers-isr' | 'domestic-swiss-credit-transfers' | 'domestic-swiss-credit-transfers-qr' | 'domestic-swiss-foreign-credit-transfers' | 'swiss-sepa-credit-transfers' | 'swiss-cross-border-credit-transfers' | 'pain.001-sepa-credit-transfers' | 'pain.001-cross-border-credit-transfers' | 'pain.001-swiss-six-credit-transfers', required - `paymentId` string, required — Resource identification of the generated payment initiation resource. ## Headers - `X-Request-ID` string, required - `Digest` string - `Signature` string - `TPP-Signature-Certificate` string, byte - `TPP-Redirect-Preferred` boolean - `TPP-Nok-Redirect-URI` string, uri - `TPP-Redirect-URI` string, uri - `TPP-Explicit-Authorisation-Preferred` boolean - `PSU-IP-Address` string, ipv4 - `PSU-IP-Port` string - `PSU-Accept` string - `PSU-Accept-Charset` string - `PSU-Accept-Encoding` string - `PSU-Accept-Language` string - `PSU-User-Agent` string - `PSU-Http-Method` 'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE' - `PSU-Device-ID` string - `PSU-Geo-Location` string ## Response `202` Received - PaymentInitiationCancelResponse202 — Body of the response for a successful cancel payment request. - `transactionStatus` 'ACCC' | 'ACCP' | 'ACSC' | 'ACSP' | 'ACTC' | 'ACWC' | 'ACWP' | 'RCVD' | 'PDNG' | 'RJCT' | 'CANC' | 'ACFC' | 'PATC' | 'PART', required — The transaction status is filled with codes of the ISO 20022 data table: - 'ACCC': 'AcceptedSettlementCompleted' - Settlement on the creditor's account has been completed. - 'ACCP': 'AcceptedCustomerProfile' - Preceding check of technical validation was successful. Customer profile check was also successful. - 'ACSC': 'AcceptedSettlementCompleted' - Settlement on the debtoro?=s account has been completed. **Usage:** this can be used by the first agent to report to the debtor that the transaction has been completed. **Warning:** this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement. - 'ACSP': 'AcceptedSettlementInProcess' - All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. - 'ACTC': 'AcceptedTechnicalValidation' - Authentication and syntactical and semantical validation are successful. - 'ACWC': 'AcceptedWithChange' - Instruction is accepted but a change will be made, such as date or remittance not sent. - 'ACWP': 'AcceptedWithoutPosting' - Payment instruction included in the credit transfer is accepted without being posted to the creditor customero?=s account. - 'RCVD': 'Received' - Payment initiation has been received by the receiving agent. - 'PDNG': 'Pending' - Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. - 'RJCT': 'Rejected' - Payment initiation or individual transaction included in the payment initiation has been rejected. - 'CANC': 'Cancelled' Payment initiation has been cancelled before execution Remark: This codeis accepted as new code by ISO20022. - 'ACFC': 'AcceptedFundsChecked' - Preceding check of technical validation and customer profile was successful and an automatic funds check was positive . Remark: This code is accepted as new code by ISO20022. - 'PATC': 'PartiallyAcceptedTechnical' Correct The payment initiation needs multiple authentications, where some but not yet all have been performed. Syntactical and semantical validations are successful. Remark: This code is accepted as new code by ISO20022. - 'PART': 'PartiallyAccepted' - A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status. Remark: This code may be used only in case of bulk payments. It is only used in a situation where all mandated authorisations have been applied, but some payments have been rejected. - `scaMethods` AuthenticationObject[] — This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access token is transported. If this data element is contained, then there is also a hyperlink of type 'startAuthorisationWithAuthenticationMethodSelection' contained in the response body. These methods shall be presented towards the PSU for selection by the TPP. - `authenticationType` 'SMS_OTP' | 'CHIP_OTP' | 'PHOTO_OTP' | 'PUSH_OTP' | 'SMTP_OTP', required — Type of the authentication method. More authentication types might be added during implementation projects and documented in the ASPSP documentation. - 'SMS_OTP': An SCA method, where an OTP linked to the transaction to be authorised is sent to the PSU through a SMS channel. - 'CHIP_OTP': An SCA method, where an OTP is generated by a chip card, e.g. a TOP derived from an EMV cryptogram. To contact the card, the PSU normally needs a (handheld) device. With this device, the PSU either reads the challenging data through a visual interface like flickering or the PSU types in the challenge through the device key pad. The device then derives an OTP from the challenge data and displays the OTP to the PSU. - 'PHOTO_OTP': An SCA method, where the challenge is a QR code or similar encoded visual data which can be read in by a consumer device or specific mobile app. The device resp. the specific app than derives an OTP from the visual challenge data and displays the OTP to the PSU. - 'PUSH_OTP': An OTP is pushed to a dedicated authentication APP and displayed to the PSU. - 'SMTP_OTP': An OTP is sent via email to the PSU. - `authenticationVersion` string — Depending on the "authenticationType". This version can be used by differentiating authentication tools used within performing OTP generation in the same authentication type. This version can be referred to in the ASPSP?s documentation. - `authenticationMethodId` string, required — An identification provided by the ASPSP for the later identification of the authentication method selection. - `name` string — This is the name of the authentication method defined by the PSU in the Online Banking frontend of the ASPSP. Alternatively this could be a description provided by the ASPSP like "SMS OTP on phone +49160 xxxxx 28". This name shall be used by the TPP when presenting a list of authentication methods to the PSU, if available. - `explanation` string — Detailed information about the SCA method for the PSU. - `chosenScaMethod` ChosenScaMethod — Authentication object. - `authenticationType` 'SMS_OTP' | 'CHIP_OTP' | 'PHOTO_OTP' | 'PUSH_OTP' | 'SMTP_OTP', required — Type of the authentication method. More authentication types might be added during implementation projects and documented in the ASPSP documentation. - 'SMS_OTP': An SCA method, where an OTP linked to the transaction to be authorised is sent to the PSU through a SMS channel. - 'CHIP_OTP': An SCA method, where an OTP is generated by a chip card, e.g. a TOP derived from an EMV cryptogram. To contact the card, the PSU normally needs a (handheld) device. With this device, the PSU either reads the challenging data through a visual interface like flickering or the PSU types in the challenge through the device key pad. The device then derives an OTP from the challenge data and displays the OTP to the PSU. - 'PHOTO_OTP': An SCA method, where the challenge is a QR code or similar encoded visual data which can be read in by a consumer device or specific mobile app. The device resp. the specific app than derives an OTP from the visual challenge data and displays the OTP to the PSU. - 'PUSH_OTP': An OTP is pushed to a dedicated authentication APP and displayed to the PSU. - 'SMTP_OTP': An OTP is sent via email to the PSU. - `authenticationVersion` string — Depending on the "authenticationType". This version can be used by differentiating authentication tools used within performing OTP generation in the same authentication type. This version can be referred to in the ASPSP?s documentation. - `authenticationMethodId` string, required — An identification provided by the ASPSP for the later identification of the authentication method selection. - `name` string — This is the name of the authentication method defined by the PSU in the Online Banking frontend of the ASPSP. Alternatively this could be a description provided by the ASPSP like "SMS OTP on phone +49160 xxxxx 28". This name shall be used by the TPP when presenting a list of authentication methods to the PSU, if available. - `explanation` string — Detailed information about the SCA method for the PSU. - `challengeData` ChallengeData — It is contained in addition to the data element 'chosenScaMethod' if challenge data is needed for SCA. In rare cases this attribute is also used in the context of the 'startAuthorisationWithPsuAuthentication' link. - `image` string, byte — PNG data (max. 512 kilobyte) to be displayed to the PSU, Base64 encoding, cp. [RFC4648]. This attribute is used only, when PHOTO_OTP or CHIP_OTP is the selected SCA method. - `data` string[] — A collection of strings as challenge data. - `imageLink` string — A link where the ASPSP will provides the challenge image for the TPP. - `otpMaxLength` integer — The maximal length for the OTP to be typed in by the PSU. - `otpFormat` 'characters' | 'integer' — The format type of the OTP to be typed in. The admitted values are "characters" or "integer". - `additionalInformation` string — Additional explanation for the PSU to explain e.g. fallback mechanism for the chosen SCA method. The TPP is obliged to show this to the PSU. - `_links` LinksPaymentInitiationCancel — A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. Remark: All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): * 'startAuthorisation': In case, where just the authorisation process of the cancellation needs to be started, but no additional data needs to be updated for time being (no authentication method to be selected, no PSU identification nor PSU authentication data to be uploaded). * 'startAuthorisationWithPsuIdentification': In case where a PSU identification needs to be updated when starting the cancellation authorisation: The link to the cancellation-authorisations end-point, where the cancellation sub-resource has to be generated while uploading the PSU identification data. * 'startAuthorisationWithPsuAuthentication': In case of a yet to be created authorisation sub-resource: The link to the cancalation authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU authentication data. * 'startAuthorisationWithEncryptedPsuAuthentication': Same as startAuthorisactionWithPsuAuthentication where the authentication data need to be encrypted on application layer in uploading. * 'startAuthorisationWithAuthenticationMethodSelection': The link to the authorisation end-point, where the cancellation-authorisation sub-resource has to be generated while selecting the authentication method. This link is contained under exactly the same conditions as the data element 'scaMethods' - `startAuthorisation` HrefType — Link to a resource. - `href` string — Link to a resource. - `startAuthorisationWithPsuIdentification` HrefType — Link to a resource. - `href` string — Link to a resource. - `startAuthorisationWithPsuAuthentication` HrefType — Link to a resource. - `href` string — Link to a resource. - `startAuthorisationWithEncryptedPsuAuthentication` HrefType — Link to a resource. - `href` string — Link to a resource. - `startAuthorisationWithAuthenticationMethodSelection` HrefType — Link to a resource. - `href` string — Link to a resource. ## Other responses - `204` — No Content - `400` — Bad Request - `401` — Unauthorized - `403` — Forbidden - `404` — Not found - `405` — Method Not Allowed - `406` — Not Acceptable - `408` — Request Timeout - `409` — Conflict - `415` — Unsupported Media Type - `429` — Too Many Requests - `500` — Internal Server Error - `503` — Service Unavailable --- [API](https://skmtc.net/openbankingproject-ch/apis/swiss-nextgen-banking-api-framework.md) · [All operations](https://skmtc.net/openbankingproject-ch/apis/swiss-nextgen-banking-api-framework/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/openbankingproject-ch/swiss-nextgen-banking-api-framework/revisions/c32e86db40b4/schema)