= Payment Processor Account **Payment Processor** which will handle `transaction.init` API call is determined based on : - `ptnr_id` value, which is implicitly known from Authentication Credentials for API call - `pp_type` parameter in request By default, these 2 parameters (`ptnr_id` and `pp_type`) further determine **Payment Processor Account** that will be used for transaction. Depending on exact **Payment Processor** additional request parameters could be used to determine appropriate **Payment Processor Account**: - **Netbilling** additionally uses `currency` parameter from request (__required__) - **PayOn** can use `currency` and `bank_country` parameters from request (both are optional) - **PayU** can additionally use `currency` and `country` parameters from request (both are optional) Once we have **Payment Processor Account** determined we know which **Payment Processor** and which **Merchant account** account to use on that **Payment Processor** for **Transaction**. = Overrides **Overrides** allow **Partner** to use different **Payment Processor Account** than one which would be determined with default process described above. Different **Payment Processor Account** also means that completely different **Payment Processor** can be used for **Transaction** (in this case parameter `pp_type` from `transaction.init` request is overridden as well). **Overrides** are activated by passing parameters into `transaction.init` API call : - `override` - int, __required__ (for example on #dating this is `company_id`) - `override_tag` - int, __required__ (for example on #dating this is `site_id`) - `override_type` - string, optional, recognized values are: - `''` (empty string, default value) or - `'x-sale'` - `currency` - __required__ for `transaction.init` API call - `ptnr_id` - implicitly known from Authentication Credentials for API call. These parameters are matched against `overrides` table. If match is found it will override **Payment Processor Account** that would be used by default. Match data from `overrides` table will give us - `ppac_id` - override for **Payment Processor Account** (and consequently **Payment Processor**) - `force_mid` - when used with **Rocket Gate** it sets appropriate `merchantSiteID` parameter for API call to **Rocket Gate**; when used with **Netbilling** it sets appropriate `processor` parameter for API call to **Netbilling**; otherwise not used. - `force_acc` - **Rocket Gate** specific, if set it will set appropriate `merchantAccount` parameter for API call to **Rocket Gate** = Usage in Transaction Determined **Payment Processor Account** (`ppac_id`), along with other overrides parameters ( `force_mid`, `force_acc` ) is saved into **Order** when making `transaction.init` API call. Same **Payment Processor Account** and overrides parameters are then used for `transaction.finish` API call (call that matches `transaction.init` call). This means that **Transaction** is executed on **Payment Processor Account** determined with process described above.

= Payment Processor Account **Payment Processor** which will handle [[public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] API call is determined based on : - `ptnr_id` value, which is implicitly known from Authentication Credentials for API call - `pp_type` parameter in request By default, these 2 parameters (`ptnr_id` and `pp_type`) further determine **Payment Processor Account** that will be used for transaction. Depending on exact **Payment Processor** additional request parameters could be used to determine appropriate **Payment Processor Account**: - **Netbilling** additionally uses `currency` parameter from request (__required__) - **PayOn** can use `currency` and `bank_country` parameters from request (both are optional) - **PayU** can additionally use `currency` and `country` parameters from request (both are optional) Once we have **Payment Processor Account** determined we know which **Payment Processor** and which **Merchant account** account to use on that **Payment Processor** for **Transaction**. = Overrides **Overrides** allow **Partner** to use different **Payment Processor Account** than one which would be determined with default process described above. Different **Payment Processor Account** also means that completely different **Payment Processor** can be used for **Transaction** (in this case parameter `pp_type` from public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] request is overridden as well). **Overrides** are activated by passing parameters into [[public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] API call : - `override` - int, __required__ (for example on #dating this is `company_id`) - `override_tag` - int, __required__ (for example on #dating this is `site_id`) - `override_type` - string, optional, recognized values are: - `''` (empty string, default value) or - `'x-sale'` - `currency` - __required__ for `transaction.init` API call - `ptnr_id` - implicitly known from Authentication Credentials for API call. These parameters are matched against `overrides` table. If match is found it will override **Payment Processor Account** that would be used by default. Match data from `overrides` table will give us - `ppac_id` - override for **Payment Processor Account** (and consequently **Payment Processor**) - `force_mid` - when used with **Rocket Gate** it sets appropriate `merchantSiteID` parameter for API call to **Rocket Gate**; when used with **Netbilling** it sets appropriate `processor` parameter for API call to **Netbilling**; otherwise not used. - `force_acc` - **Rocket Gate** specific, if set it will set appropriate `merchantAccount` parameter for API call to **Rocket Gate** = Usage in Transaction Determined **Payment Processor Account** (`ppac_id`), along with other overrides parameters ( `force_mid`, `force_acc` ) is saved into **Order** when making [[public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] API call. Same **Payment Processor Account** and overrides parameters are then used for next appropriate [[public/payment/partners/apidocs/transaction.finish/ | `transaction.finish`]] API call. This means that **Transaction** is executed on **Payment Processor Account** determined with process described above.

= Payment Processor Account **Payment Processor** which will handle [[public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] API call is determined based on : - `ptnr_id` value, which is implicitly known from Authentication Credentials for API call - `pp_type` parameter in request By default, these 2 parameters (`ptnr_id` and `pp_type`) further determine **Payment Processor Account** that will be used for transaction. Depending on exact **Payment Processor** additional request parameters could be used to determine appropriate **Payment Processor Account**: - **Netbilling** additionally uses `currency` parameter from request (__required__) - **PayOn** can use `currency` and `bank_country` parameters from request (both are optional) - **PayU** can additionally use `currency` and `country` parameters from request (both are optional) Once we have **Payment Processor Account** determined we know which **Payment Processor** and which **Merchant account** account to use on that **Payment Processor** for **Transaction**. = Overrides **Overrides** allow **Partner** to use different **Payment Processor Account** than one which would be determined with default process described above. Different **Payment Processor Account** also means that completely different **Payment Processor** can be used for **Transaction** (in this case parameter `pp_type` from public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] request is overridden as well). **Overrides** are activated by passing parameters into [[public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] API call : - `override` - int, __required__ (for example on #dating this is `company_id`) - `override_tag` - int, __required__ (for example on #dating this is `site_id`) - `override_type` - string, optional, recognized values are: - `''` (empty string, default value) or - `'x-sale'` - `currency` - __required__ for `transaction.init` API call - `ptnr_id` - implicitly known from Authentication Credentials for API call. These parameters are matched against `overrides` table. If match is found it will override **Payment Processor Account** that would be used by default. Match data from `overrides` table will give us - `ppac_id` - override for **Payment Processor Account** (and consequently **Payment Processor**) - `force_mid` - when used with **Rocket Gate** it sets appropriate `merchantSiteID` parameter for API call to **Rocket Gate**; when used with **Netbilling** it sets appropriate `processor` parameter for API call to **Netbilling**; otherwise not used. - `force_acc` - **Rocket Gate** specific, if set it will set appropriate `merchantAccount` parameter for API call to **Rocket Gate** = Usage in Transaction Determined **Payment Processor Account** (`ppac_id`), along with other overrides parameters ( `force_mid`, `force_acc` ) is saved into **Order** when making [[public/payment/partners/apidocs/transaction.init/ | `transaction.init`]] API call. Same **Payment Processor Account** and overrides parameters are then used for `transaction.finish` API call (call that matchesnext appropriate [[public/payment/partners/apidocs/transaction.finish/ | `transaction.init`finish`]] API call). This means that **Transaction** is executed on **Payment Processor Account** determined with process described above.