Finqware

Getting started

FinqLink WebUI

Security

Overview

How-to

Create Link

Get Link

List Links

List Providers

Get Provider

Callback redirect

Link API - Alpha

Finqware Link API

FinqLink

Sandbox

Production

<h3 class="slate-h3 " >Overview</h3><p class="slate-p " ><code class="slate-code">Pay-by-link</code> is a method that breaks the payment process in two distinct phases:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">the creation of a payment request, operated by the creditor (receiver of funds)</div></li><li class="slate-li " ><div style="position:relative">the acceptance &amp; authorization of the payment, operated by the debtor (the source of funds)</div></li></ul><p class="slate-p " >The payment request encapsulates metadata such as: amount, currency, the list of goods to be acquired etc. Once its created, the payment request is wrapped into a transportable object - aka <code class="slate-code">the link</code>- such as a URL or a QR code. The link is sent to a debtor who will only check/approve &amp; authorize the payment.</p><p class="slate-p " >FinqLink is a <span style="color:rgb(0, 0, 0)">platform for developing pay-by-link applications</span>, built on top of the Finqware Payments API. <span style="color:rgb(0, 0, 0)">It comes with a simple API for generating payment links and a web application for operating the links. </span></p><h3 class="slate-h3 " >Payment providers</h3><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">A <code class="slate-code">payment-provider</code> is a partner institution that operates payment services. FinqLink integrates with these providers over APIs such as open-banking payment initiation APIs. </div></li><li class="slate-li " ><div style="position:relative">Each provider has a unique code. Eg: <code class="slate-code">rzb_ro</code>, <code class="slate-code">cec_ro</code> etc.</div></li><li class="slate-li " ><div style="position:relative">A provider may have one or multiple <code class="slate-code">payment-methods</code> offering different capabilities (domestic-only transfers, corporate-only transfers etc)</div></li><li class="slate-li " ><div style="position:relative">we provide an API and a <a href="https://pay.finqware.com/web/v1/providers" target="_blank">dashboard</a> for quering and visualising all the details regarding providers &amp; methods.</div></li></ul><h3 class="slate-h3 " >How to test</h3><ol class="slate-ol " ><li class="slate-li " ><div style="position:relative">Get a set of API test credentials (contact Finqware)</div></li><li class="slate-li " ><div style="position:relative">Use the <code class="slate-code">/providers/list</code> endpoint to query for the available/supported payment providers.</div></li><li class="slate-li " ><div style="position:relative">Create a payment link using the <code class="slate-code">/links/create</code> endpoint. The <code class="slate-code">payment-method</code> will be used to restrict more or less the options shown to the end-user when opening the payment link. </div></li><li class="slate-li " ><div style="position:relative">Send the payment link to someone in order to operate the payment.</div></li></ol><h3 class="slate-h3 " >Sandbox testing</h3><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><code class="slate-code">rzb_ro</code> - debtor IBAN: <code class="slate-code">RO03RZBR0000069999999999</code>, creditor IBAN: <code class="slate-code">RO10RZBR0000069999999970</code>, PSU ID: <code class="slate-code">9999999998</code></div><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Test scenarios: (1) submit the debtor IBAN and/or PSU ID via the API; (2) do not submit them, let the user do the input</div></li></ul></li><li class="slate-li " ><div style="position:relative"><code class="slate-code">bt_ro</code> - username: <code class="slate-code">testbt</code>, password: <code class="slate-code">testbt</code>, pin: <code class="slate-code">1234567</code></div></li><li class="slate-li " ><div style="position:relative"><code class="slate-code">cec_ro</code> - username: <code class="slate-code">testcecapi</code>, password: <code class="slate-code">testcecapi</code>, IBAN: <code class="slate-code">RO42CECEAG0202RON0007466</code></div></li></ul><p class="slate-p " ></p><p class="slate-p " ></p>

 is a method that breaks the payment process in two distinct phases:

The payment request encapsulates metadata such as: amount, currency, the list of goods to be acquired etc. Once its created, the payment request is wrapped into a transportable object - aka 

- such as a URL or a QR code. The link is sent to a debtor who will only check/approve & authorize the payment.

platform for developing pay-by-link applications

, built on top of the Finqware Payments API. 

It comes with a simple API for generating payment links and a web application for operating the links. 

FinqLink API is secured by OAuth2 and mTLS

<p class="slate-p" placeholder="Type / for widgets">The Link API is secured by OAuth2 (mandatory for production access) and mTLS (optional).</p><p class="slate-p" placeholder="Type / for widgets">Mutual TLS (mTLS) and OAuth2 Client Credentials are two distinct security mechanisms that can complement each other to provide robust authentication and secure communication in API integrations. </p><p class="slate-p" placeholder="Type / for widgets">Note: for testing purposes we also support an internal authentication method that requires client_id/client_secret with each API call. The code examples in this document use this particular method.</p><h2 class="slate-h2">Mutual TLS (mTLS)</h2><p class="slate-p" placeholder="Type / for widgets"><strong class="slate-bold">mTLS</strong> is a mechanism for ensuring that both the client and server authenticate each other over a TLS connection. It is an extension of standard TLS (which typically only authenticates the server to the client).</p><ul class="slate-ul"><li class="slate-li"><div style="position:relative"><strong class="slate-bold">How mTLS Works:</strong></div><ol class="slate-ol"><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Client Authentication</strong>: In addition to the server presenting its certificate, the client also presents its own certificate to the server.</div></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Certificate Verification</strong>: Both parties verify the certificates they receive. This ensures that both the client and server are who they claim to be, providing bidirectional authentication.</div></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Secure Communication</strong>: Once both parties are authenticated, a secure encrypted communication channel is established.</div></li></ol></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Benefits of mTLS:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative">Strong, cryptographic client authentication.</div></li><li class="slate-li"><div style="position:relative">Prevents unauthorized clients from connecting to the server.</div></li><li class="slate-li"><div style="position:relative">Ensures data integrity and confidentiality during transmission.</div></li></ul></li></ul><h2 class="slate-h2">OAuth2 Client Credentials Grant</h2><p class="slate-p" placeholder="Type / for widgets"><strong class="slate-bold">OAuth2 Client Credentials Grant</strong> is a method for obtaining access tokens that can be used to authenticate requests to an API. It is typically used when a client (such as a service or application) needs to access resources or APIs on behalf of itself, not on behalf of a user.</p><ul class="slate-ul"><li class="slate-li"><div style="position:relative"><strong class="slate-bold">How OAuth2 Client Credentials Grant Works:</strong></div><ol class="slate-ol"><li class="slate-li"><div style="position:relative">The client (service or application) authenticates with the authorization server using its client ID and secret.</div></li><li class="slate-li"><div style="position:relative">If the credentials are valid, the authorization server issues an access token.</div></li><li class="slate-li"><div style="position:relative">The client uses this access token to authenticate its requests to the resource server (API).</div></li></ol></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Benefits of OAuth2 Client Credentials:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative">Provides a mechanism for API clients to obtain access tokens for authenticating requests.</div></li><li class="slate-li"><div style="position:relative">Supports fine-grained authorization and scopes to control access to resources.</div></li><li class="slate-li"><div style="position:relative">Enables centralized management of client credentials and access policies.</div></li></ul></li></ul><h3 class="slate-h3">Private Key JWT</h3><p class="slate-p" placeholder="Type / for widgets">Private Key JWT is a method of client authentication where the client creates and signs a JWT using its own private key. This method is described in a combination of RFC 7521 (Assertion Framework) and RFC 7523 (JWT Profile for Client Authentication, and referenced by OpenID Connect and FAPI 2.0 Security Profile.</p><p class="slate-p" placeholder="Type / for widgets">Although we support the Client Secret (RFC 6749) authentication, we recommend Private Key JWT as it does not involve a process of sharing secrets.</p><h2 class="slate-h2">How mTLS and OAuth2 Client Credentials Complement Each Other</h2><p class="slate-p" placeholder="Type / for widgets">When used together, <strong class="slate-bold">mTLS</strong> and <strong class="slate-bold">OAuth2 Client Credentials Grant</strong> provide a powerful combination of strong client authentication and fine-grained authorization. Here’s how they complement each other:</p><ol class="slate-ol"><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Dual Authentication and Authorization:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative"><strong class="slate-bold">mTLS</strong> provides a strong, cryptographic client authentication mechanism, ensuring that only authorized clients (those with valid client certificates) can establish a connection.</div></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">OAuth2 Client Credentials</strong> provides a token-based mechanism for authorizing the client&apos;s access to specific APIs or resources. The access token contains information about the client&apos;s permissions and access scope.</div></li></ul></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Layered Security:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative">By using both mTLS and OAuth2, you establish multiple layers of security. Even if an access token is somehow obtained by an attacker, mTLS ensures that only clients with a valid certificate can connect. Conversely, even if a client possesses a valid certificate, it still needs a valid access token to access protected resources.</div></li></ul></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Preventing Token Theft and Replay Attacks:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative">With mTLS, the secure communication channel prevents token theft during transmission. Even if a token were somehow intercepted, it would be useless without the client&apos;s certificate to establish the connection.</div></li></ul></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Enhanced Security for Sensitive Applications:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative">For highly sensitive applications, combining mTLS with OAuth2 Client Credentials ensures that only authenticated clients (validated by their certificates) and authorized clients (validated by their tokens) can access resources. This is particularly important in zero-trust environments or for internal microservices communication.</div></li></ul></li><li class="slate-li"><div style="position:relative"><strong class="slate-bold">Compliance and Regulatory Requirements:</strong></div><ul class="slate-ul"><li class="slate-li"><div style="position:relative">Some industries require strong client authentication and end-to-end encryption. Combining mTLS with OAuth2 can help meet these regulatory requirements by ensuring secure communication and controlled access.</div></li></ul></li></ol><h2 class="slate-h2">Summary</h2><p class="slate-p" placeholder="Type / for widgets">By combining mTLS with OAuth2 Client Credentials Grant, you gain the benefits of both strong client authentication and fine-grained access control, enhancing the overall security posture of your application.</p>

The Link API is secured by OAuth2 (mandatory for production access) and mTLS (optional).

Mutual TLS (mTLS) and OAuth2 Client Credentials are two distinct security mechanisms that can complement each other to provide robust authentication and secure communication in API integrations. 

Note: for testing purposes we also support an internal authentication method that requires client_id/client_secret with each API call. The code examples in this document use this particular method.

 is a mechanism for ensuring that both the client and server authenticate each other over a TLS connection. It is an extension of standard TLS (which typically only authenticates the server to the client).

 is a method for obtaining access tokens that can be used to authenticate requests to an API. It is typically used when a client (such as a service or application) needs to access resources or APIs on behalf of itself, not on behalf of a user.

Private Key JWT is a method of client authentication where the client creates and signs a JWT using its own private key. This method is described in a combination of RFC 7521 (Assertion Framework) and RFC 7523 (JWT Profile for Client Authentication, and referenced by OpenID Connect and FAPI 2.0 Security Profile.

Although we support the Client Secret (RFC 6749) authentication, we recommend Private Key JWT as it does not involve a process of sharing secrets.

How mTLS and OAuth2 Client Credentials Complement Each Other

 provide a powerful combination of strong client authentication and fine-grained authorization. Here’s how they complement each other:

By combining mTLS with OAuth2 Client Credentials Grant, you gain the benefits of both strong client authentication and fine-grained access control, enhancing the overall security posture of your application.

<h2 class="slate-h2 " >mTLS</h2><p class="slate-p " >Setting up mTLS requires two steps. Please contact us for:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">enabling your API Client for mTLS</div></li><li class="slate-li " ><div style="position:relative">sharing your certificate/s in order to be added to our PKI infrastructure</div></li></ul><h3 class="slate-h3 " >Certificate requirements</h3><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Certificates must use either RSA or ECDSA ciphers.</div></li><li class="slate-li " ><div style="position:relative">For client (leaf) certificates:</div><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">The <a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.9" target="_blank">Basic Constraints</a> extension must <em class="slate-italic">not</em> contain <span style="color:var(--devsite-code-color)"><code class="slate-code">CA=true</code></span>.</div></li><li class="slate-li " ><div style="position:relative">The <a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12" target="_blank">Extended Key Usage</a> extension must contain <span style="color:var(--devsite-code-color)"><code class="slate-code">clientAuth</code></span>.</div></li><li class="slate-li " ><div style="position:relative">The <a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12" target="_blank">Extended Key Usage</a> extension must <em class="slate-italic">not</em> contain the <span style="color:var(--devsite-code-color)"><code class="slate-code">codeSigning</code></span>, <span style="color:var(--devsite-code-color)"><code class="slate-code">timeStamping</code></span>, or <span style="color:var(--devsite-code-color)"><code class="slate-code">OCSPSigning</code></span> fields.</div></li><li class="slate-li " ><div style="position:relative">The certificate must not be expired.</div></li><li class="slate-li " ><div style="position:relative">The client certificate cannot be a <a href="https://en.wikipedia.org/wiki/Self-signed_certificate" target="_blank">self-signed certificate</a>.</div></li></ul></li><li class="slate-li " ><div style="position:relative">For root and intermediate certificates:</div><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">The <a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.9" target="_blank">Basic Constraints</a> extension must contain <span style="color:var(--devsite-code-color)"><code class="slate-code">CA=true</code></span>.</div></li><li class="slate-li " ><div style="position:relative">The <a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3" target="_blank">Key Usage</a> extension must be set to <span style="color:var(--devsite-code-color)"><code class="slate-code">keyCertSign</code></span>.</div></li><li class="slate-li " ><div style="position:relative">The <a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12" target="_blank">Extended Key Usage</a> extension should contain the <span style="color:var(--devsite-code-color)"><code class="slate-code">clientAuth</code></span> field.</div></li><li class="slate-li " ><div style="position:relative">The certificate must not be expired.</div></li></ul></li></ul><h2 class="slate-h2 " >OAuth2</h2><p class="slate-p " >Setting up OAuth2 requires few steps. Please contact us for:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">enabling your API Client for OAuth2</div></li><li class="slate-li " ><div style="position:relative">sharing the public key which we&apos;ll use to verify the signed requests to our Authorization server (<a href="https://gist.github.com/mitel/e95f77c94bb21bacbd457d77ef5f1709" target="_blank">example</a> script for generating the public/private key pair)</div></li></ul><h3 class="slate-h3 " >Getting an access token</h3><p class="slate-p " >Making requests to the Link API in production requires a valid Bearer access token, sent via the standard <code class="slate-code">Authorization</code> header. The process below describes the way to acquire an access token (<a href="https://gist.github.com/mitel/36b88d6c50afe02be11d5fb8f00888a5" target="_blank">example</a> script for local tests with curl/Postman)</p><p class="slate-p " >Your backend is responsible to implement a mechanism for keeping an up-to-date access-token available at all times. There are mature libraries for implementing this process, available in all mainstream programming languages (eg: <a href="https://github.com/jwtk/jjwt" target="_self">Java</a>, <a href="https://github.com/jwtk/njwt" target="_self">NodeJS</a>). </p><p class="slate-p " >Step-1: build a token with a payload such as below and sign it with your private key. The signed token is called a <code class="slate-code">client_assertion</code> in OAuth2 terms.</p><p class="slate-p " >The example below assumes your client_id is <code class="slate-code">xyz123abc</code> and key id (kid): <code class="slate-code">a1b2c3</code>:</p><p class="slate-p " >The JSON Header has to specify your key id (kid):</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">Plain text</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"> </textarea><code class="language-json keep-markup drop-tokens"><div class="slate-code_line">{
  &quot;alg&quot;: &quot;RS256&quot;,
  &quot;typ&quot;: &quot;JWT&quot;,
  &quot;kid&quot;: &quot;a1b2c3&quot;
}</div></code></pre></div><p class="slate-p " >The JSON payload:</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">JSON</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"> </textarea><code class="language-json keep-markup drop-tokens"><div class="slate-code_line"><div class="slate-code_line">{
  &quot;aud&quot;: &quot;https://finqware.okta.com/oauth2/ausfqbxutkZBUKUgQ417/v1/token&quot;,
  &quot;iss&quot;: &quot;xyz123abc&quot;,
  &quot;sub&quot;: &quot;xyz123abc&quot;,
  &quot;iat&quot;: 1741161292,
  &quot;exp&quot;: 1741164892,
  &quot;jti&quot;: &quot;9CF1E…479C&quot;
}</div></div></code></pre></div><p class="slate-p " >Step-2: use the <code class="slate-code">client_assertion</code> computed above to make a call to our <code class="slate-code">/token</code> endpoint in order to get an access-token.</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">Plain text</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"> </textarea><code class="language-bash keep-markup drop-tokens"><div class="slate-code_line">curl --location --request POST &apos;https://finqware.okta.com/oauth2/ausfqbxutkZBUKUgQ417/v1/token&apos; \</div><div class="slate-code_line">    --header &apos;Accept: application/json&apos; \</div><div class="slate-code_line">    --header &apos;Content-Type: application/x-www-form-urlencoded&apos; \</div><div class="slate-code_line">    --data-urlencode &apos;client_id=xyz123abc&apos; \</div><div class="slate-code_line">    --data-urlencode &apos;grant_type=client_credentials&apos; \</div><div class="slate-code_line">    --data-urlencode &apos;scope=pay_by_link&apos; \</div><div class="slate-code_line">    --data-urlencode &apos;client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&apos; \</div><div class="slate-code_line">    --data-urlencode &apos;client_assertion=eyJhbGciOiJSUzI1NiIsIn....le3qGb5mp-yUmPqUwoyZaA9g&apos;</div></code></pre></div><p class="slate-p " >Use the received access-token for making calls to the Link API until its expiration (each access-token is valid for a limited time).</p><p class="slate-p " ></p>

Setting up mTLS requires two steps. Please contact us for:

Setting up OAuth2 requires few steps. Please contact us for:

Making requests to the Link API in production requires a valid Bearer access token, sent via the standard 

 header. The process below describes the way to acquire an access token (

 script for local tests with curl/Postman)

Your backend is responsible to implement a mechanism for keeping an up-to-date access-token available at all times. There are mature libraries for implementing this process, available in all mainstream programming languages (eg: 

Step-1: build a token with a payload such as below and sign it with your private key. The signed token is called a 

The example below assumes your client_id is 

The JSON Header has to specify your key id (kid):

 endpoint in order to get an access-token.

Use the received access-token for making calls to the Link API until its expiration (each access-token is valid for a limited time).

<p class="slate-p " >Create a new payment link.</p><p class="slate-p " >There are three flows currently supported (set via options/type):</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><code class="slate-code">link</code>: a standard transportable payment link. Offers maximum flexibility in terms of expiration and user optionality. Use this flow when generating payment links expected to be operated after a longer time. Example: an invoice sent over email which you don&apos;t expect an immediate action for.</div></li><li class="slate-li " ><div style="position:relative"><code class="slate-code">wrapped_sca</code>: a transportable payment link for immediate usage. The authorisation URL is requested at link creation, hence there is no optionality anymore for the user to choose a different payment provider. Use this flow when (1) you know upfront all the payment details and (2) you expect immediate action from your user, as the authorisation URL may expire in minutes.</div></li><li class="slate-li " ><div style="position:relative"><code class="slate-code">direct_sca</code>: a non-transportable payment link. This is a native authorisation URL received from the payment provider. Only available to regulated companies under PSD2 (PISP). </div></li></ul><p class="slate-p " ></p>

There are three flows currently supported (set via options/type):

client_id

A secret used for authenticating & authorising your client app. Not required for OAuth2-enabled clients.

client_secret

options

A set of filters for restricting payment-methods.

payment_method

single_transfer

Content-Type

Required for OAuth2-enabled clients (mandatory for production)

Authorization

request_id

created_at

expires_at

link_id

web_id

The name of the client app that generated the link.

api_client_app

web_url

qr_code

error_id

code

message

<p class="slate-p" placeholder="Type / for widgets">Retrieve information on an existing payment link.</p><p class="slate-p" placeholder="Type / for widgets"></p><p class="slate-p" placeholder="Type / for widgets"></p><p class="slate-p" placeholder="Type / for widgets"></p>

Retrieve information on an existing payment link.

The ID of the link to retrieve. This is a required parameter and should be a unique identifier for the link

is_expired

An id associated to the API request, for debugging purposes.

status

A user-facing web endpoint for operating the payment link.

<p class="slate-p " >List the links owned by an application identified by the client_id.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

List the links owned by an application identified by the client_id.

A list of links owned by the registered app identified by client_id.

links

<p class="slate-p " >List the supported payment-providers. You may check our <a href="https://pay.finqware.com/web/v1/providers" target="_blank">dashboard</a> built on top of this API for an overview.</p><p class="slate-p " ></p><div class="slate-div"></div><p class="slate-p " ></p><div class="slate-div"></div><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

List the supported payment-providers. You may check our 

 built on top of this API for an overview.

Filter for a specific list of service providers and their details.

filter

Options for showing service provider details

providers

<p class="slate-p " >Details on a particular payment-provider. You may check our <a href="https://pay.finqware.com/web/v1/providers" target="_blank">dashboard</a> built on top of this API for an overview.</p><div class="slate-div"></div><p class="slate-p " ></p><div class="slate-div"></div><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

Details on a particular payment-provider. You may check our 

provider_id

Please check the 'options' field from the /providers/list endpoint.

provider

<p class="slate-p " >A redirect endpoint used for <code class="slate-code">direct_sca</code> flows only (available only to PIS-regulated entities).</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

 flows only (available only to PIS-regulated entities).

The query string received from the bank via redirect.

query_string

If true, the request will await for a final status from the service provider, attempted by our backend in a background process.

Sections