Payment security and testing

Built-in controls

• High-entropy credential used only server-to-server, with separate payment permission.
• Durable intent before any external initiation.
• Profile, beneficiary, payment reference, amount and institution fixed and validated by the server.
• Encrypted sensitive state; widget token bound to company, intent, expiry and origin, stored only as a hash.
• Deterministic attempt identifiers and fencing to prevent automatic re-initiation after an ambiguous outcome.
• Dedicated callback, single consumption, optimistic version control and lease.
• Redacted audit records: never include credentials, full IBANs, IP addresses, callbacks, complete responses or opaque state.
• Explicitly allowed destinations and redirects, with HTTPS, timeouts and bounded responses.
• Widget messaging with exact origin matching, event.source validation and a versioned schema.

Integrate the sandbox

Request the following from Wealth Reader:

1. a private credential authorized for payments and the required profile;
2. the exact HTTPS origin that will host the widget;
3. the agreed amount and frequency limits;
4. access to sandbox mode, which does not move money.

Always query profile-institutions; in sandbox it returns only a simulated institution. Create the intent with expected_mode: "mock" and check that the response attestation also indicates mock before delivering the token to the browser.

Test at least:

• repeated creation with the same key, and a conflict with a different body;
• an altered institution or mode;
• an expired token and a disallowed origin;
• a blocked popup and the SCA return;
• an intermediate pending state, reconciliation and widget closure;
• confirmation only on receiving payment_status: settled.

Request live activation

Before a test involving money, confirm with Wealth Reader:

• that the institution appears in the preliminary query for your credential;
• that the profile and its version are approved;
• that the origin, callback and SCA flow have been validated end-to-end;
• that amount, frequency, reconciliation and emergency shutdown limits are in place;
• that an authorized person is responsible for the minimal test.

Some institutions may require the source account; in that case, the widget requests it during authorization. The user's network address is derived at the API's controlled boundary; the client must not send it. Neither this data nor the debtor IBAN is exposed in events.

The curl sequence prepares and queries the intent, but does not complete bank authentication. The user must continue in the browser or banking application.

Profile activation requires three independent, exact deployment controls: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04, and the credential's company included in WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. These values do not replace payment permission or enable a real institution on their own.

The currently published contract marks psuIp as unused, but historical connector tests required it. Wealth Reader keeps activation blocked until both the exact field and the trusted proxy policy are verified in the target deployment through an approved options test and end-to-end test. Activation must not rely on arbitrary forwarded headers or assume that the published declaration reflects historical behavior.

Private DNS resolution and TLS termination towards the internal service depend on each deployment: this SDK does not assume that they exist or are reachable. They must be verified from the API runtime before enabling outbound traffic or accepting new intents.

What not to do

• Send the API key, full beneficiary details or internal data to the browser.
• Invent an institution that was not returned by the preliminary query.
• Automatically repeat an ambiguous initiation.
• Log an IBAN, network address, callback or complete bank response.
• Interpret the end of the interaction as settlement.
• Reuse bank aggregation routes, tokens or callbacks.