# Frequently Asked Questions
source: https://developer.mastercard.com/open-banking-connect/documentation/frequently-asked-questions/index.md

### Open Banking General FAQ {#open-banking-general-faq}

Payment requests currently use either of three payment products: Domestic Credit Transfers or SEPA Credit Transfers. The flow is the same regardless of which is used by the targeted ASPSP. We will use the Domestic Credit Transfer option for purposes of this illustration.

Steps to initiate a payment request:

1. Create a consent for the PSU (*/payments/domestic-credit-transfer/consents*)
2. Redeem the payment request (*/payments/domestic-credit-transfer* )
   * The status and details of the payment may also be requested at a later time.
3. Check the payment status: (*/payments/domestic-credit-transfer/payment-status*)
4. Get the details of the payment status from the ASPSP: (*/payments/domestic-credit-transfer/payment-details*)

### Conditions {#conditions}

Each message specification data field/element includes the following condition codes. Each condition is described in the respective request or response.

* O (Optional): The field is supported by the API, but the usage is optional.
* C (Conditional): The field is required by the API under certain conditions (see "Description").
* M (Mandatory): The field is always required by the API.

*** ** * ** ***

### Multiplicity {#multiplicity}

Multiplicity indicates the cardinality of the elements in the message structure:

* (0..1) -- 0 or 1 instances of the element
* (1..1) -- exactly one instance of the element only
* (0..N) -- 0 to N instances of the element

*** ** * ** ***

### Interface API structure {#interface-api-structure}

The API Interface is resource oriented. Resources are addressed under the API endpoints.

For example: \<`https://{provider}/{service}`\>

Where

* {provider} is the host and path of the API.
* {service} has the values consents, payments, accounts, eventually extended by more information on product types and request scope.

*** ** * ** ***

### API Profiles {#api-profiles}

All ASPSPs that can be accessed through Mastercard Open Banking Connect have a descriptor that indicates the API Profile of the ASPSP, that is, the Open Banking API standard implemented on the side of the ASPSP. As of the Drop 2 release, Open Banking Connect provides access only to ASPSPs that have one of the following API profiles:

* **CMA9** -- An Open Banking API standard defined by the Open Banking Implementation Entity (OBIE) in UK, which is mandatory for the nine major banks, per the order from Competition and Markets Authority (CMA). Currently this API profile is based on v2.0.0 of the OBIE specification for AIS and on v1.1.0 of the OBIE specification PIS.

* **PolishAPI** -- An Open Banking API standard for the banking sector in Poland currently based on v2.1.2 of the Polish API specification.

* **NextGenPSD2** -- An Open Banking API standard defined by Berlin Group for the EU banking sector. They developed the standard to create uniform and interoperable communications between EU banks and TPPs.

* **STET** - An Open Banking API standard defined by group of major French banks for full range of payment instruments in the French and Belgian market.

The API Profile enables the TPP to determine if the original API standard of the ASPSP supports a specific endpoint included in Open Banking Connect. The endpoints specifications included in this document provide details of the supported API Profile.

The API returns the API Profile for each ASPSP when the TPP requests the list of ASPSPs.

### Consent Management FAQ {#consent-management-faq}

Consent is an integral part of PSD2 and collaboration with 3rd parties. The only way Third Party Payment Service Providers can act on the customers' behalf is if the customer has given explicit consent (authorization) to have such permissions. The process by which a PSU gives a TPP permission to approach their ASPSP in order that the TPP can be granted access to the PSU's account to provide the service to the PSU is called Consent. The process by which the PSU confirms that the ASPSP may respond to the request from the TPP to whom the PSU has given consent. It is between the TPP and customer to agree the time period for account data sharing, known as customer consent. Regardless of the time period agreed, PSD2 SCA regulation requires us to ask the customer to re-authenticate at least every 180 days. A string of letters and digits that represent a code that is sent to TPP as part of a query string in the redirect URL when PSU is taken from ASPSP page to TPP's webpage/app following consent approval. Authorization code is sent by TPP to ASPSP in order to receive back data to access payment details or account details (for example to receive back: access token, refresh token, consentId, other consent related data). `scaRedirect` is a bank's URL where the PSU can login and approve the transaction. Your application has to extract the following information from Consent Redirect Url:

* `consentId` - To be used for credit transfer.
* `consentRequestId` - The same as what is received in the response for payments/consent API call, this way your application can find for which basket the consent has been received.
* `POST: /accounts/consents/authorizations` - Exchanges the PSU authorization for access consent.
* `POST: /accounts/consents/raw` - Extracts the original account information raw consent given by the ASPSP and can be used for validation.
* `POST: /payments/consents/raw` - Extracts the original payment initiation raw consent given by the ASPSP and can be used for validation.

### Pre-Prod environment FAQ {#pre-prod-environment-faq}

No additional TPP onboarding is needed to use PRE-PROD. However, TPPs should contact their Mastercard representative to define the list of ASPSPs they want to work with in PRE-PROD. If the TPP is not yet registered with any ASPSPs, they will need to go through the standard registration process before those ASPSPs can be added. If a TPP intends to use a different, separate redirect URI that is not registered with the ASPSP, they should register it with the ASPSP first. It is recommended that TPPs restrict access to PSUs to applicable members, such as friends and family testing, Beta users. This is because PRE-PROD is a live environment provided by Open Banking Connect in addition to Sandbox and Production and available to customers to perform live proving and testing activities. PRE-PROD has been built as a close replica of Production. For example, most of the services available for Production have been replicated on PRE-PROD with the exception of Reporting / Power BI. All transactions in PRE-PROD will work the same as Production transactions. For example, payments will involve real money movement and account information service will involve real account data movement. PRE-PROD releases will be performed at the same time as Sandbox releases. In this way, TPPs can do live proving of new functionalities or new ASPSPs before the code is released in Production and affects real customers.

### Variable Recurring Payments FAQ {#variable-recurring-payments-faq}

Variable Recurring Payment (VRP\*) provides recurring funds movement within UK accounts using Open Banking (faster payment) without the need of user authentication (SCA at bank) for each payment.
Note: \*PISP and VRP APIs are independent. VRP Sweeping (mandatory for CMA9 ASPSPs) allows users to authorize fund movement between two accounts in their name; e.g. top up savings account.