Payment Submission Services (PSS)

Overview and Scope

The Payment Submission Service (PSS) enables Service Users (SU) to submit payment instructions to a Service Provider (SP) for further processing and execution.

PSS is a submission service. It does not directly initiate, approve or execute payments. All payments submitted via PSS must be explicitly confirmed by the customer in the Service Provider’s e-banking channel before they can be executed.

The service is based on the Swiss Payment Standards (SPS) and is designed in alignment with the ISO 20022 message model. Payment submission follows the structure and semantics of ISO 20022 credit transfer messages, while the retrieval of submission status reflects the ISO 20022 status report concept. The standard applies to file-based submissions using pain.001 / pain.002 messages as well as to requests through the JSON-based API.

The PSS API is owned and orchestrated by SFTI. If you want to know more about the release cycle or contribute to the API specification, visit our Release Management section. bLink acts as a standardized, secure connectivity and API delivery platform offering the service.

Functional Scope

Payment Submission Services refer to the delivery of payment instructions from a Service User to a Service Provider. Submitted payments are acknowledged and processed by the Service Provider and must be approved by the customer in their corresponding e-banking before execution.

Payment Submission

PSS is designed to support payment types as defined by the Swiss Payment Standards (SPS), including in particular:

• D – Domestic payments
  • IBAN payments
  • Swiss QR-bill payments
• S – SEPA credit transfers
• X – Cross-border payments or domestic payments in foreign currencies

Booking Structures

A payment submission may contain:

• Single bookings or
• Batch bookings, consisting of multiple payment instructions within one submission

Advice Handling

The Payment Submission Service is designed to support the advice options defined by the Swiss Payment Standards (SPS):

• No debit or credit advice
• Individual debit or credit advice
• Collective debit or credit advice
  • With details
  • Without details

Submission Formats

PSS offers two equivalent submission methods, both aligned with Swiss Payment Standards and providing the same functional capabilities.

ISO 20022 XML

• pain.001 for payment submission via POST/iso20022/payments (Currently version pain.001.001.09 is supported)
• pain.002 for status reporting via GET/iso20022/{submissionId}/status (Currently version pain.002.001.10 is supported)

JSON-based API

• Payment submission via POST/payments
• Status report via GET/payments/{submissionId}/status

The JSON format represents a defined subset of ISO 20022, covering the essential attributes required for payment submission while enabling dynamic, API-driven interaction.

Payment Status

PSS offers standardized transparency regarding the status of submitted payments in accordance with Swiss Payment Standards and the ISO 20022 status report concept.

The status information is exposed on two levels:

• Submission (group-level) status, reflecting the overall outcome of a payment submission
• Instruction-level status, reflecting the outcome of individual payment instructions within a submission

Submission (Group-Level) Status

The group-level status represents the consolidated outcome of the submitted payment group:

• RCVD: The payment submission has been received and is under processing.
• ACCP: The payment submission has been accepted. All included payment instructions are technically and functionally valid.
• RJCT: The payment submission has been rejected. None of the payment instructions are accepted.
• PART: The payment submission is partially accepted. At least one payment instruction is accepted and at least one is rejected.

Instruction-Level Status

Each individual payment instruction within a submission may have one of the following statuses:

• ACCP – Accepted
• RJCT – Rejected

Instruction-level statuses are particularly relevant when the submission status is PART.

Relation to other Services

The Payment Submission Service focuses exclusively on submission and submission-level status visibility.

Once payments are executed and booked, the resulting account transactions become available via Account Information Services and camt statements.

Payment Submission Lifecycle

The following lifecycle corresponds to the Payment Submission Service sequence diagram.

1. Create Payment Instruction

The Service User creates a payment instruction within its application based on customer input.

2. Submit Payment Instruction

The Service User submits the payment instruction to the Service Provider via bLink using:

• ISO 20022 (pain.001) or
• JSON-based API

bLink securely transmits the request to the Service Provider.

Upon receipt, the Service Provider performs technical validation, including:

• Conformance with the applicable specification
• Structural and syntactical checks

If the submission is accepted:

• HTTP status code 201 Created is returned
• A submissionId is assigned
• The Location header references the created resource

If the submission is rejected:

• An appropriate HTTP status code 4xx is returned
• The submission is not persisted
• No submissionId is assigned

3. Technical Validation and Status Processing

After acceptance, the Service Provider performs further technical and functional checks according to internal rules.

During this phase, submission-level and instruction-level statuses are determined.

4. Retrieve Submission Status

The Service User can retrieve the status of a submission using:

• GET/iso20022/payments/{submissionID}/status or
• GET/payments/{submissionId}/status

bLink forwards the request and returns the status response from the Service Provider.

5. Customer Approval in e-Banking

If payment instructions are accepted, they will be shown in the Service Provider’s e-banking channel.

Customer approval is required prior to execution.

Some Service Providers offer user-friendly correction mechanisms within their e-banking, for example:

• Adjusting an execution date that lies in the past
• Resolving insufficient funds before approval

These and any subsequent interactions take place entirely outside the PSS API.

6. Further Payment Processing and Execution

Once approved, payments enter the Service Provider’s regular payment processing pipeline and are executed according to their internal procedures.

7. Transaction Visibility

Once payments are executed and booked, the resulting account transactions become available via Account Information Services and camt statements.