Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-3105

Update criteria for assigning offsite payment accounts to an existing customer

    Details

    • Type: Story
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.5.2
    • Fix Version/s: 4.8.0-b1
    • Component/s: Gateways
    • Labels:
      None

      Description

      Using the client_reference_id field when passing to gateways that store offsite (e.g. MerchantCcOffsite, MerchantAchOffsite), the client_reference_id on a different payment account in Blesta may be stale and no longer be valid as a customer on the gateway.

      The resolution would be two-fold:

      1. Update the core Accounts::getClientReferenceId to check that the status is 'active'.
        • Only use old active payment accounts as a reference, as they are most likely to be valid.
        • Order by the most recent account, as it is most likely to be valid.
        • Also accept another optional argument, type, that can be used to specify whether to check CC or ACH accounts for a client reference ID, and use that one. This has the caveat of creating separate customer accounts for CC and ACH payment accounts on the gateway. GatewayPayments::storeAccount will need to be updated to pass the type to that method call.
      2. Each gateway that stores offsite with ::storeCc or ::storeAch should be updated to check that the client_reference_id provided is actually valid, and if not, create a new account that can be used for the client_reference_id for the payment account.
        • Each gateway should be a subtask in this story

      When creating a payment account using Authorize.net CIM (tokenization) an error may be encountered:

      E00040 The record cannot be found. See https://developer.authorize.net/api/reference/features/errorandresponsecodes.html

      This seems to occur when a Payment account was previously created, and then deleted under the client. In the accounts_ach (and possibly accounts_cc for Credit Cards) table, the record exists but the status is marked as "inactive". The client_reference_id from this inactive Payment Account is passed along when making a createCustomerPaymentProfileRequest to Authorize.net while adding a new Payment Account. Creating a new Payment Account should not pass along the client_reference_id for the inactive Payment Account. At least I don't think so.

        Activity

        admin Paul Phillips created issue -
        admin Paul Phillips made changes -
        Field Original Value New Value
        Rank Ranked higher
        admin Paul Phillips made changes -
        Rank Ranked lower
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.8.0 Sprint 1 [ 92 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        jonathan Jonathan Reissmueller made changes -
        Assignee Jonathan Reissmueller [ jonathan ]
        tyson Tyson Phillips (Inactive) made changes -
        Issue Type Bug [ 1 ] Story [ 7 ]
        tyson Tyson Phillips (Inactive) made changes -
        Fix Version/s 4.8.0-b1 [ 11127 ]
        Fix Version/s Short Term [ 10800 ]
        tyson Tyson Phillips (Inactive) made changes -
        Description When creating a payment account using Authorize.net CIM (tokenization) an error may be encountered:

        E00040 The record cannot be found. See https://developer.authorize.net/api/reference/features/errorandresponsecodes.html

        This seems to occur when a Payment account was previously created, and then deleted under the client. In the accounts_ach (and possibly accounts_cc for Credit Cards) table, the record exists but the status is marked as "inactive". The client_reference_id from this inactive Payment Account is passed along when making a createCustomerPaymentProfileRequest to Authorize.net while adding a new Payment Account. Creating a new Payment Account should not pass along the client_reference_id for the inactive Payment Account. At least I don't think so.
        Using the _client_reference_id_ field when passing to gateways that store offsite (e.g. _MerchantCcOffsite_, _MerchantAchOffsite_), the _client_reference_id_ on a different payment account in Blesta may be stale and no longer be valid as a customer on the gateway.

        The resolution would be two-fold:
        # Update the core _Accounts::getClientReferenceId_ to check that the status is 'active'.
        #* Only use old active payment accounts as a reference, as they are most likely to be valid.
        #* Order by the most recent account, as it is most likely to be valid.
        #* Also accept another optional argument, _type_, that can be used to specify whether to check CC or ACH accounts for a client reference ID, and use that one. This has the caveat of creating separate customer accounts for CC and ACH payment accounts on the gateway. _GatewayPayments::storeAccount_ will need to be updated to pass the type to that method call.
        # Each gateway that stores offsite with _::storeCc_ or _::storeAch_ should be updated to check that the _client_reference_id_ provided is actually valid, and if not, create a new account that can be used for the _client_reference_id_ for the payment account.


        ----

        When creating a payment account using Authorize.net CIM (tokenization) an error may be encountered:

        E00040 The record cannot be found. See https://developer.authorize.net/api/reference/features/errorandresponsecodes.html

        This seems to occur when a Payment account was previously created, and then deleted under the client. In the accounts_ach (and possibly accounts_cc for Credit Cards) table, the record exists but the status is marked as "inactive". The client_reference_id from this inactive Payment Account is passed along when making a createCustomerPaymentProfileRequest to Authorize.net while adding a new Payment Account. Creating a new Payment Account should not pass along the client_reference_id for the inactive Payment Account. At least I don't think so.
        tyson Tyson Phillips (Inactive) made changes -
        Summary Authorize.net CIM - Deleting and creating a new payment account may result in an error Update criteria for assigning offsite payment accounts to an existing customer
        tyson Tyson Phillips (Inactive) made changes -
        Description Using the _client_reference_id_ field when passing to gateways that store offsite (e.g. _MerchantCcOffsite_, _MerchantAchOffsite_), the _client_reference_id_ on a different payment account in Blesta may be stale and no longer be valid as a customer on the gateway.

        The resolution would be two-fold:
        # Update the core _Accounts::getClientReferenceId_ to check that the status is 'active'.
        #* Only use old active payment accounts as a reference, as they are most likely to be valid.
        #* Order by the most recent account, as it is most likely to be valid.
        #* Also accept another optional argument, _type_, that can be used to specify whether to check CC or ACH accounts for a client reference ID, and use that one. This has the caveat of creating separate customer accounts for CC and ACH payment accounts on the gateway. _GatewayPayments::storeAccount_ will need to be updated to pass the type to that method call.
        # Each gateway that stores offsite with _::storeCc_ or _::storeAch_ should be updated to check that the _client_reference_id_ provided is actually valid, and if not, create a new account that can be used for the _client_reference_id_ for the payment account.


        ----

        When creating a payment account using Authorize.net CIM (tokenization) an error may be encountered:

        E00040 The record cannot be found. See https://developer.authorize.net/api/reference/features/errorandresponsecodes.html

        This seems to occur when a Payment account was previously created, and then deleted under the client. In the accounts_ach (and possibly accounts_cc for Credit Cards) table, the record exists but the status is marked as "inactive". The client_reference_id from this inactive Payment Account is passed along when making a createCustomerPaymentProfileRequest to Authorize.net while adding a new Payment Account. Creating a new Payment Account should not pass along the client_reference_id for the inactive Payment Account. At least I don't think so.
        Using the _client_reference_id_ field when passing to gateways that store offsite (e.g. _MerchantCcOffsite_, _MerchantAchOffsite_), the _client_reference_id_ on a different payment account in Blesta may be stale and no longer be valid as a customer on the gateway.

        The resolution would be two-fold:
        # Update the core _Accounts::getClientReferenceId_ to check that the status is 'active'.
        #* Only use old active payment accounts as a reference, as they are most likely to be valid.
        #* Order by the most recent account, as it is most likely to be valid.
        #* Also accept another optional argument, _type_, that can be used to specify whether to check CC or ACH accounts for a client reference ID, and use that one. This has the caveat of creating separate customer accounts for CC and ACH payment accounts on the gateway. _GatewayPayments::storeAccount_ will need to be updated to pass the type to that method call.
        # Each gateway that stores offsite with _::storeCc_ or _::storeAch_ should be updated to check that the _client_reference_id_ provided is actually valid, and if not, create a new account that can be used for the _client_reference_id_ for the payment account.
        #* Each gateway should be a subtask in this story


        ----

        When creating a payment account using Authorize.net CIM (tokenization) an error may be encountered:

        E00040 The record cannot be found. See https://developer.authorize.net/api/reference/features/errorandresponsecodes.html

        This seems to occur when a Payment account was previously created, and then deleted under the client. In the accounts_ach (and possibly accounts_cc for Credit Cards) table, the record exists but the status is marked as "inactive". The client_reference_id from this inactive Payment Account is passed along when making a createCustomerPaymentProfileRequest to Authorize.net while adding a new Payment Account. Creating a new Payment Account should not pass along the client_reference_id for the inactive Payment Account. At least I don't think so.
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.8.0 Sprint 1 [ 92 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked lower
        tyson Tyson Phillips (Inactive) made changes -
        Story Points 5
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.8.0 Sprint 1 [ 92 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        Automated transition triggered when Jonathan Reissmueller created a branch in Stash -
        Status Open [ 1 ] In Progress [ 3 ]
        jonathan Jonathan Reissmueller made changes -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 1 hour, 27 minutes [ 5220 ]
        Worklog Id 12611 [ 12611 ]
        Automated transition triggered when Jonathan Reissmueller created pull request #746 in Stash -
        Status In Progress [ 3 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.8.0 Sprint 1 [ 92 ] 4.8.0 Sprint 1, 4.8.0 Sprint 2 [ 92, 93 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 hour, 27 minutes [ 5220 ] 1 hour, 47 minutes [ 6420 ]
        Worklog Id 12676 [ 12676 ]
        Automated transition triggered when Tyson Phillips (Inactive) merged pull request #746 in Stash -
        Status In Review [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            jonathan Jonathan Reissmueller
            Reporter:
            admin Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              23/Dec/19

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 2 hours, 56 minutes
              2h 56m

                Agile