BridgeConnecteurStable

Sync PSP payment (Bridge)

Explicitly synchronizes the state of a Bridge payment transaction to the corresponding Ormuz `platform.psp_payment`.

PSP payment

Payment transaction Bridge

Synchroniser un paiement PSP (Bridge)

Payment transaction Bridge

PSP payment

Vue d’ensemble

Sync Bridge PSP payment is the explicit point where a Bridge transaction state becomes a status change on the Ormuz platform.psp_payment.

The node rereads the current Ormuz payment before updating it so an older event cannot regress a payment that is already terminal.

Bridge amount and currency must match the Ormuz payment when present.
CREA, ACTC, and PDNG remain pending; only ACSC becomes succeeded and RJCT becomes failed.
A contradictory terminal transition is rejected rather than overwritten.

Typical scenario

A process triggered by extension.bridge.payment_transaction_terminal receives the Bridge transaction and associated psp_payment. This node applies the final result to the Ormuz payment, after which the process can start business reconciliation.

Quick start

Always provide the relevant psp_payment and the Bridge transaction correlated to the same payment.

Expected inputs

psp_payment existant
Corresponding Bridge payment_transaction

After synchronization

Use the returned psp_payment
Start reconciliation only when your business logic allows it

Configuration example

Parameter	Binding	Role
`psp_payment`	`event.psp_payment`	Correlated Ormuz payment
`payment_transaction`	`event.payment_transaction`	Terminal or reread Bridge transaction

Key point Never map PDNG to success in parallel logic: this node deliberately preserves it as pending.

Process example

PSP payment + Payment transaction Bridge

Synchroniser un paiement PSP (Bridge)

Payment transaction Bridge + PSP payment

Exemple simplifié d’utilisation de Synchroniser un paiement PSP (Bridge) dans un processus Ormuz.

Data resolution

The node resolves this data from its inputs and Bridge context.

Data	Source or rule
Current payment	Reread from `psp_payment.id` before any mutation.
Target status	`ACSC` → `succeeded`, `RJCT` → `failed`, other states → `pending`.
Received amount	The full `psp_payment` amount only when status becomes `succeeded`; otherwise the already-recorded value is preserved.
Traceability	Bridge transaction, Payment Request, and Payment Link identifiers available in payment metadata when they exist.

Parameters 3

Contexte principal

Objects and configuration that determine the Bridge operation.

extension_config_idRequisref(extension_config:bridge)

Active Bridge configuration used for this operation. It determines the Bridge API credentials and environment; the merchant remains the merchant of the current process.

psp_paymentRequisPSP payment

Existing Ormuz PSP payment already created and belonging to the process. For Bridge payment nodes, its amount and currency are the source of truth and are not requested again as separate parameters.

payment_transactionRequisBridge payment transaction

Bridge payment transaction to retrieve or synchronize. For Ormuz synchronization, it must correspond to the same payment as the supplied psp_payment.

Outputs 4

Payment

Objects and state resulting from the payment lifecycle.

payment_requestOptionnelBridge payment request

Bridge Payment Request associated with the payment, including its state and known transactions. It may be absent until Bridge has created the corresponding request.

payment_transactionBridge payment transaction

Bridge transaction representing the bank initiation and its execution state (CREA, ACTC, PDNG, ACSC, or RJCT).

psp_paymentPSP payment

Ormuz PSP payment after synchronization with Bridge state. Its amount and currency remain those of the original Ormuz payment.

Session and traceability

Session identifiers, mappings, and creation indicators.

extension_object_mappingextension object mapping

Traceability link between the primary Bridge object produced by the node and the Ormuz object with which it is associated.

Behavior

Reread the PSP payment

The node works from the current Ormuz state rather than a potentially stale process snapshot.

Validate the transaction

Checks amount and currency consistency when Bridge supplies them.

Protect terminal states

An existing terminal state is not regressed to pending; a terminal contradiction is rejected.

Update and trace

Applies the allowed status and returns the refreshed payment and transaction mapping.

Limits and responsibilities

The node does not create a psp_payment: it must already exist.
It does not automatically reconcile the payment with an invoice, order, or receivable.
The Bridge PART status, used in some provider contexts, is not treated as partially_funded in the Ormuz model for this flow.
A contradiction between two terminal statuses is treated as an error to investigate.

Troubleshooting

Inconsistent amount or currency

Check that the Bridge transaction actually comes from the initiation created for this psp_payment and that two payments have not been mixed.

The status remains succeeded despite a late PDNG

This is intentional: a less advanced event cannot regress a terminal payment.

Terminal transition rejected

A payment already succeeded cannot become failed (or vice versa) without explicit investigation of the provider conflict.

Reference

Bridge status	Ormuz PSP status
`CREA`	`pending`
`ACTC`	`pending`
`PDNG`	`pending`
`ACSC`	`succeeded`
`RJCT`	`failed`