Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 5.6.0-b1
-
Component/s: None
-
Labels:None
Description
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database.
$status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database.2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class
Example would be the `captureStoredCc()` function.
When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled.There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error.
3.
Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe.This is happening inside of app/controllers/client_pay.php
As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay
Activity
| Field | Original Value | New Value |
|---|---|---|
| Sprint | 5.6.0 Sprint 4 [ 168 ] |
| Rank | Ranked higher |
| Assignee | Abdy Franco [ abdy ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Remaining Estimate | 0 minutes [ 0 ] | |
| Time Spent | 4 hours, 21 minutes [ 15660 ] | |
| Worklog Id | 16021 [ 16021 ] |
| Status | In Progress [ 3 ] | In Review [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. 3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay. {quote} |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. -3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay.- {quote} |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. -3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay.- {quote} |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} -3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay.- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} -3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay.- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} -3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} -3. Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of `app/controllers/client_pay.php` As `confirm()` gets called again as its loading that page with an error message it ends up calling `buildPaymentConfirmation()` for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to -pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. In other words you have an error and a pending transaction in blesta all on one attempt to -pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. This is happening inside of app/controllers/client_pay.php As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. -This is happening inside of app/controllers/client_pay.php- As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. -This is happening inside of app/controllers/client_pay.php- As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. -This is happening inside of app/controllers/client_pay.php- -As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
| Description |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. {quote} 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. -This is happening inside of app/controllers/client_pay.php- -As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- |
{quote}
1. There are multiple switch cases in this class that incorrectly name decline which causes it not to be saved correctly in database. $status = ‘decline’ should be changed to $status = ‘declined’ in all instances to match the enum in the database. 2. The handleApiRequest() function does not consistently return data that is needed for other functions in that class Example would be the `captureStoredCc()` function. When Stripe returns `requires_payment_method` error code the $captured_payment_intent variable ends up containing and array instead of an object. This ends up skipping the switch statement and marking resulting error code output not clear for the end user. It also incorrectly handles what that error actually is. Since in some instances that is returned because of a failed 3d secure attempt, it would be better to handle that as a decline state since the transaction cannot move forward. It also needs to set the transaction in stripe via api as canceled. There is also a need of testing `requires_payment_method` further to make sure we cover all instances of that error, but canceled and declined should be a good solution as that is considered an error. 3. -Last issue we ran in to was after an error (sometimes a decline) occurs it causes blesta to start a new transaction in stripe-. -This is happening inside of app/controllers/client_pay.php- -As confirm() gets called again as its loading that page with an error message it ends up calling buildPaymentConfirmation() for the second time that initiates the initial pending state in blesta and a payment started in stripe. -In other words you have an error and a pending transaction in blesta all on one attempt to pay- {quote} |
| Status | In Review [ 5 ] | Closed [ 6 ] |
