First of all rebill process is separated into 2 processes, each of them has some limitations and separate rules. Rebill processing and rebill scheduling are taking place at different moments and has different constrains. In both cases rebill and user related subscription can be canceled and no further processing will take place. **Rebill scheduling** Is executed every 15 minutes and it’s main purpose is to schedule rebill for every active subscription in the system. If rebill scheduling is not possible subscription status might be changed during scheduling process. Scheduling result for single subscription might end up with: # **Adding new rebill schedule and keeping active subscription status** # Based on last/previous rebill transaction status: - **NONE** (Only initial transaction before) Add new schedule: Just add new first rebill to schedule - **Succesful** - Add new schedule with full item price - Add new schedule with stepped down amount: - NOTE: if last 2 successful rebills were “stepped down”, meaning they haven’t been charged by full item price, maximum value of last 2 successful attempts will be taken (T6790). So if user last 2 transactions of 29.00 subscription was billed with 1.99 next amount will be 1.99 again (and never be higher!) - worth to consider to drop # **Failed** - Rebill retry plan has to exists! Otherwise we will never rebill this item again. - Rebill retry plan found and possible (next) step down # Not adding new rebill schedule and changing subscription status to: # Completed # Only when subscription has predefined number of billing cycles and reaches that number (max_rebill_count). # Suspended It can be activated automatically by PV2 when we will get info from external processor (eg. PayPal) that they managed to charge user. - For unsupported processor type (meaning: we don’t initiate rebill for this processor) with exceeded expected rebill date (based on subscription setup) - For unsupported processor type (meaning: we don’t initiate rebill for this processor) without defined last transaction status or without any transactions - For unsupported processor type (meaning: we don’t initiate rebill for this processor) with last transactions status failed - For supported processors (eg RG) when last transaction returned NSF (608 status code, (not suitable funds) and next attempt (according to Rebill Retry Plan) will keep amount the same (T19714#416545) - For supported processors (eg RG) when new rebill amount (based on step downs in rebill retry plan) will be lowered than 1USD (or other currency) - For supported processors when card has estimated balance and according to rebill retry plan new calculated amount (might be any RBRP step) can’t ever been lower than estimated balance # Canceled - Wrong item definition, rebill and trial periods = 0 - CC bin is on one of the lists here (NOT IN USE, CAN WE DROP?) - - https://www.dvippay.com/payment_processors_rules/view?id=775 - - https://www.dvippay.com/payment_processors_rules/view?id=213 **Rebill processing** In general scheduling service is making decisions about further rebill attempts. But under some specific requirement rebel script can also put subscription into “inactive” status that will end up with not further rebill attempts. Preprocessing possible scenarios. Meaning rebill responds before hitting external gateway (RG). 661 (Blocked for selected countries or currencies, RU/RUB currently), attempt marked as failed - it will retry according to rebill retry plan (but will fail if no block for that coutries removed) 680 - blocked by Bin Optimizer 814 - very rate (CC expired and no quess formula found) NOTE: if we will discover that CC data is expired, we will try to guess new expire date (based on some old rules) 671 - below balance (non - realoadable card + estimated balance < than requested amount) Codes resulting in immediate subscription cancel and no further processing (scheduling) PCODE_RESTRICTED_CC = 611 (Your credit card was blocked by the issuing financial institution. Please try another card). RocketGate reasonCodes mapped to 611: 108 (Declined - Call : The bank has declined the transaction and has requested that the merchant call.) 109 (Declined - Pickup Card : The bank has declined the transaction and has requested that the merchant pickup the card.) 200 (Declined - Scrub : Transaction was declined due to fraud scrubbing.) 201(Declined - Blocked : Transaction was declined due to the customer's account being blocked.) Alternatively bankResponseCode: 57, 05-TransNotAllow, -840047, 05-PickupCardSpe, -840006, ) PCODE_CC_INVALID = 601 (Credit Card number is not valid). RocketGate reasonCodes mapped to 611: 111 Alternatively bankResponseCode: 14 PCODE_IMMEDIATE_SUSPEND = 672 (Transaction declined and any recurring subs will be suspended). RocketGate reasonCodes mapped to 611: bankResponseCode: 79 PCODE_BIN_OPTIMIZER_BLOCKED = 680 (Transaction declined because of BinOptimizer ratio below 1%) PCODE_DECLINED_3DS_20_FINGERPRINT_REQUIRED = 631 (Transaction was declined because 3-D Secure 2.0 fingerprint is required) reasonCode: 225 When card is expired and any guessing attempt hasn’t resulted in successful response

First of all rebill process is separated into 2 processes, each of them has some limitations and separate rules. Rebill processing and rebill scheduling are taking place at different moments and has different constrains. In both cases rebill and user related subscription can be canceled and no further processing will take place. **Rebill scheduling** Is executed every 15 minutes and it’s main purpose is to schedule rebill for every active subscription in the system. If rebill scheduling is not possible subscription status might be changed during scheduling process. Scheduling result for single subscription might end up with: # **Adding new rebill schedule and keeping active subscription status** # Based on last/previous rebill transaction status: - **NONE** (Only initial transaction before) Add new schedule: Just add new first rebill to schedule - **Succesful** - Add new schedule with full item price - Add new schedule with stepped down amount: - **RULE REMOVED** (T26089/2023-02-09) NOTE: if last 2 successful rebills were “stepped down”, meaning they haven’t been charged by full item price, maximum value of last 2 successful attempts will be taken (T6790). So if user last 2 transactions of 29.00 subscription was billed with 1.99 next amount will be 1.99 again (and never be higher!) - worth to consider to drop # **Failed** - Rebill retry plan has to exists! Otherwise we will never rebill this item again. - Rebill retry plan found and possible (next) step down # **Not adding new rebill schedule and changing subscription status to:** # **Completed** Only when subscription has predefined number of billing cycles and reaches that number (max_rebill_count). # **Suspended** It can be activated automatically by PV2 when we will get info from external processor (eg. PayPal) that they managed to charge user. - For unsupported processor type (meaning: we don’t initiate rebill for this processor) with exceeded expected rebill date (based on subscription setup) - For unsupported processor type (meaning: we don’t initiate rebill for this processor) without defined last transaction status or without any transactions - For unsupported processor type (meaning: we don’t initiate rebill for this processor) with last transactions status failed - For supported processors (eg RG) when last transaction returned NSF (608 status code, (not suitable funds) and next attempt (according to Rebill Retry Plan) will keep amount the same (T19714#416545) - For supported processors (eg RG) when new rebill amount (based on step downs in rebill retry plan) will be lowered than 1USD (or other currency) - For supported processors when card has estimated balance and according to rebill retry plan new calculated amount (might be any RBRP step) can’t ever been lower than estimated balance # **Canceled** - Wrong item definition, rebill and trial periods = 0 - CC bin is on one of the lists here (NOT IN USE, CAN WE DROP?) https://www.dvippay.com/payment_processors_rules/view?id=775 https://www.dvippay.com/payment_processors_rules/view?id=213 **Rebill processing** In general scheduling service is making decisions about further rebill attempts. But under some specific requirement rebel script can also put subscription into “inactive” status that will end up with not further rebill attempts. # **Preprocessing possible scenarios. Meaning rebill responds before hitting external gateway (RG).** - **661** (Blocked for selected countries or currencies, RU/RUB currently), attempt marked as failed - it will retry according to rebill retry plan (but will fail if no block for that coutries removed) - **680** - blocked by Bin Optimizer - **814** - very rate (CC expired and no quess formula found) - NOTE: if we will discover that CC data is expired, we will try to guess new expire date (based on some old rules) - **671** - below balance (non - realoadable card + estimated balance < than requested amount) # **Codes resulting in immediate subscription cancel and no further processing (scheduling) ** - PCODE_RESTRICTED_CC = **611** (Your credit card was blocked by the issuing financial institution. Please try another card). RocketGate reasonCodes mapped to 611: - 108 (Declined - Call : The bank has declined the transaction and has requested that the merchant call.) - 109 (Declined - Pickup Card : The bank has declined the transaction and has requested that the merchant pickup the card.) - 200 (Declined - Scrub : Transaction was declined due to fraud scrubbing.) - 201(Declined - Blocked : Transaction was declined due to the customer's account being blocked.) - Alternatively bankResponseCode: 57, 05-TransNotAllow, -840047, 05-PickupCardSpe, -840006, ) - PCODE_CC_INVALID = **601** (Credit Card number is not valid). RocketGate reasonCodes mapped to 611: - 111 - Alternatively bankResponseCode: 14 - PCODE_IMMEDIATE_SUSPEND = **672** (Transaction declined and any recurring subs will be suspended). RocketGate reasonCodes mapped to 611: - bankResponseCode: 79 - PCODE_BIN_OPTIMIZER_BLOCKED = **680** (Transaction declined because of BinOptimizer ratio below 1%) - PCODE_DECLINED_3DS_20_FINGERPRINT_REQUIRED = **631** (Transaction was declined because 3-D Secure 2.0 fingerprint is required) - reasonCode: 225 - When card is expired and any guessing attempt hasn’t resulted in successful response

First of all rebill process is separated into 2 processes, each of them has some limitations and separate rules. Rebill processing and rebill scheduling are taking place at different moments and has different constrains. In both cases rebill and user related subscription can be canceled and no further processing will take place. **Rebill scheduling** Is executed every 15 minutes and it’s main purpose is to schedule rebill for every active subscription in the system. If rebill scheduling is not possible subscription status might be changed during scheduling process. Scheduling result for single subscription might end up with: # **Adding new rebill schedule and keeping active subscription status** # Based on last/previous rebill transaction status: - **NONE** (Only initial transaction before) Add new schedule: Just add new first rebill to schedule - **Succesful** - Add new schedule with full item price - Add new schedule with stepped down amount: - **RULE REMOVED** (T26089/2023-02-09) NOTE: if last 2 successful rebills were “stepped down”, meaning they haven’t been charged by full item price, maximum value of last 2 successful attempts will be taken (T6790). So if user last 2 transactions of 29.00 subscription was billed with 1.99 next amount will be 1.99 again (and never be higher!) - worth to consider to drop # **Failed** - Rebill retry plan has to exists! Otherwise we will never rebill this item again. - Rebill retry plan found and possible (next) step down # **Not adding new rebill schedule and changing subscription status to:** # # **Completed** # Only when subscription has predefined number of billing cycles and reaches that number (max_rebill_count). # # **Suspended** It can be activated automatically by PV2 when we will get info from external processor (eg. PayPal) that they managed to charge user. - For unsupported processor type (meaning: we don’t initiate rebill for this processor) with exceeded expected rebill date (based on subscription setup) - For unsupported processor type (meaning: we don’t initiate rebill for this processor) without defined last transaction status or without any transactions - For unsupported processor type (meaning: we don’t initiate rebill for this processor) with last transactions status failed - For supported processors (eg RG) when last transaction returned NSF (608 status code, (not suitable funds) and next attempt (according to Rebill Retry Plan) will keep amount the same (T19714#416545) - For supported processors (eg RG) when new rebill amount (based on step downs in rebill retry plan) will be lowered than 1USD (or other currency) - For supported processors when card has estimated balance and according to rebill retry plan new calculated amount (might be any RBRP step) can’t ever been lower than estimated balance # # **Canceled** - Wrong item definition, rebill and trial periods = 0 - CC bin is on one of the lists here (NOT IN USE, CAN WE DROP?) - - https://www.dvippay.com/payment_processors_rules/view?id=775 - - https://www.dvippay.com/payment_processors_rules/view?id=213 **Rebill processing** In general scheduling service is making decisions about further rebill attempts. But under some specific requirement rebel script can also put subscription into “inactive” status that will end up with not further rebill attempts. # **Preprocessing possible scenarios. Meaning rebill responds before hitting external gateway (RG).** 661 - **661** (Blocked for selected countries or currencies, RU/RUB currently), attempt marked as failed - it will retry according to rebill retry plan (but will fail if no block for that coutries removed) 680 - **680** - blocked by Bin Optimizer 814 - **814** - very rate (CC expired and no quess formula found) - NOTE: if we will discover that CC data is expired, we will try to guess new expire date (based on some old rules) 671 - **671** - below balance (non - realoadable card + estimated balance < than requested amount) # **Codes resulting in immediate subscription cancel and no further processing (scheduling) ** - PCODE_RESTRICTED_CC = **611** (Your credit card was blocked by the issuing financial institution. Please try another card). RocketGate reasonCodes mapped to 611: PCODE_RESTRICTED_CC = 611 (Your credit card was blocked by the issuing financial institution. Please try another card). RocketGate reasonCodes mapped to 611: - 108 (Declined - Call : The bank has declined the transaction and has requested that the merchant call.) 108 - 109 (Declined - CallPickup Card : The bank has declined the transaction and has requested that the merchant callpickup the card.) 109 - 200 (Declined - Pickup CardScrub : The bank has declined the transaction and has requested that the merchant pickup the cardn was declined due to fraud scrubbing.) 200 - 201(Declined - ScrubBlocked : Transaction was declined due to fraud scrubbingthe customer's account being blocked.) 201(Declined - Blocked : Transaction was declined due to the customer's account being blocked. - Alternatively bankResponseCode: 57, 05-TransNotAllow, -840047, 05-PickupCardSpe, -840006, ) Alternatively bankResponseCode: 57, 05-TransNotAllow, -840047, 05-PickupCardSpe, -840006, ) - PCODE_CC_INVALID = **601** (Credit Card number is not valid). RocketGate reasonCodes mapped to 611: PCODE_CC_INVALID = 601 (Credit Card number is not valid). RocketGate reasonCodes mapped to 611: - 111 111 - Alternatively bankResponseCode: 14 Alternatively bankResponseCode: 14 - PCODE_IMMEDIATE_SUSPEND = **672** (Transaction declined and any recurring subs will be suspended). PCODE_IMMEDIATE_SUSPEND = 672 (Transaction declined and any recurring subs will be suspended). RocketGate reasonCodes mapped to 611: - bankResponseCode: 79 - PCODE_BIN_OPTIMIZER_BLOCKED = 680**680** (Transaction declined because of BinOptimizer ratio below 1%) - PCODE_DECLINED_3DS_20_FINGERPRINT_REQUIRED = 631**631** (Transaction was declined because 3-D Secure 2.0 fingerprint is required) - reasonCode: 225 - When card is expired and any guessing attempt hasn’t resulted in successful response