= 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** //Note//: if values of both, `override` and `override_tag` parameters are empty (`0` or '' - empty string), then **Overrides** mechanism won't be used, and **Payment Processor Account** will be selected by default (as described in [[ public/payment/overrides/#payment-processor-account | Payment Processor Account ]] section on this page). = 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.

NOTE: doesn't work anymore. this doc will be dropped soon = 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) ----- If **Partner** has multiple **Payment Processor Accounts** defined for some **Payment Processor** one and only one of those **Payment Processor Accounts** is chosen depending on exact **Payment Processor**: - for **Rocket Gate** - **Payment Processor Account** with lowest `ppac_id` value is chosen (first, oldest one) - for all other **Payment Processor**s - - **Payment Processor Account** with highest `ppac_id` value is chosen (last, youngest one) ----- 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_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** NOTE: Previously `transaction.init` recognized parameter `override_tag` which corresponded to `site_id` on Dating Application. However, flows of data that used this parameter are not used anymore and sending `override_tag` in `transaction.init` call is deprecated. = 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.

NOTE: doesn't work anymore. this doc will be dropped soon = 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) ----- If **Partner** has multiple **Payment Processor Accounts** defined for some **Payment Processor** one and only one of those **Payment Processor Accounts** is chosen depending on exact **Payment Processor**: - for **Rocket Gate** - **Payment Processor Account** with lowest `ppac_id` value is chosen (first, oldest one) - for all other **Payment Processor**s - - **Payment Processor Account** with highest `ppac_id` value is chosen (last, youngest one) ----- 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** //Note//: if values of both, `override` andNOTE: Previously `transaction.init` recognized parameter `override_tag` parameters are empty (`0` or '' - empty string),which corresponded to `site_id` on Dating Application. then **Overrides** mechanism won't be usedHowever, and **Payment Processor Account** will be selected by default (as described in [[ public/payment/overrides/#payment-processor-account | Payment Processor Account ]] section on this page). flows of data that used this parameter are not used anymore and sending `override_tag` in `transaction.init` call is deprecated. = 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.