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

PayPal: Store payer's email address in the transaction reference field

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.2.0
    • Fix Version/s: 4.3.0-b1
    • Component/s: Gateways
    • Labels:
      None

      Description

      When a payment is verified through non-merchant payment gateway, PayPal Payment's Standard, set the return value reference_id to the received payer email address if available, or default to the current behavior (null).


      Clients sometimes pay with a PayPal address that is different than the email provided during sign up, and it can be difficult to determine what that address is. To solve this, store the PayPal email address in the transaction "Reference #" field, where the last 4 of credit card transactions is currently stored.

        Activity

        Hide
        tyson Tyson Phillips (Inactive) added a comment -

        Is there a reason the payee email address is useful to know for a transaction? I think the PayPal reference field is currently blank and doesn't store anything like the last 4 of a CC number.

        Show
        tyson Tyson Phillips (Inactive) added a comment - Is there a reason the payee email address is useful to know for a transaction? I think the PayPal reference field is currently blank and doesn't store anything like the last 4 of a CC number.
        Hide
        admin Paul Phillips added a comment -

        The payee email address is useful because:

        • It is useful for quickly finding their transactions in PayPal.
        • It can also be helpful in identifying fraud. I often check Tools > Logs > Gateway, and parse through the raw response to determine the payee email so that I can see if it's the same or different than the email the client provided.
        Show
        admin Paul Phillips added a comment - The payee email address is useful because: It is useful for quickly finding their transactions in PayPal. It can also be helpful in identifying fraud. I often check Tools > Logs > Gateway, and parse through the raw response to determine the payee email so that I can see if it's the same or different than the email the client provided.
        Hide
        tyson Tyson Phillips (Inactive) added a comment -

        The PayPal IPN documentation says that the payer email is always the primary email address for their account, so I don't think this would be useful for your use case where they pay with an alternate email address. No other variables are provided from PayPal to specifically identify the email address used to make the payment according to their documentation.

        Show
        tyson Tyson Phillips (Inactive) added a comment - The PayPal IPN documentation says that the payer email is always the primary email address for their account, so I don't think this would be useful for your use case where they pay with an alternate email address. No other variables are provided from PayPal to specifically identify the email address used to make the payment according to their documentation.
        Hide
        admin Paul Phillips added a comment -

        The PayPal IPN documentation says that the payer email is always the primary email address for their account, so I don't think this would be useful for your use case where they pay with an alternate email address. No other variables are provided from PayPal to specifically identify the email address used to make the payment according to their documentation.

        The payer email is always the primary email address for their PayPal account. It is often different than the email they provide when creating an account in Blesta. We just want to know what the PayPal email is of the account making the payment as it may and often will differ from that of their Blesta account.

        Show
        admin Paul Phillips added a comment - The PayPal IPN documentation says that the payer email is always the primary email address for their account, so I don't think this would be useful for your use case where they pay with an alternate email address. No other variables are provided from PayPal to specifically identify the email address used to make the payment according to their documentation. The payer email is always the primary email address for their PayPal account. It is often different than the email they provide when creating an account in Blesta. We just want to know what the PayPal email is of the account making the payment as it may and often will differ from that of their Blesta account.
        Hide
        tyson Tyson Phillips (Inactive) added a comment -

        The gateway may also determine which client the payment is set to based on the payer email. Should that behavior no longer occur? If there exists another client account in the system, they could pay as one client and the payment could be applied to another.

        Show
        tyson Tyson Phillips (Inactive) added a comment - The gateway may also determine which client the payment is set to based on the payer email. Should that behavior no longer occur? If there exists another client account in the system, they could pay as one client and the payment could be applied to another.
        Hide
        admin Paul Phillips added a comment - - edited

        The gateway may also determine which client the payment is set to based on the payer email. Should that behavior no longer occur? If there exists another client account in the system, they could pay as one client and the payment could be applied to another.

        The client ID is included when a payment is initiated by Blesta so that Blesta knows where to apply the PayPal payment regardless of email as it is included in the IPN call. The issue comes into play when data is imported into Blesta from a competitor and the client has a PayPal Subscription; in this case, client ID does not exist and a match on email is attempted, and the payment is not applied if a match cannot be found. This is a separate issue with a straightforward solution: Subscription ID's. PayPal provides a subscription ID for each subscription. We should really be storing this, and referencing the subscription ID rather than the email for such payments. I created CORE-2367 to deal with this.

        Edit: To answer your question, we should not change the behavior if email match is only performed when client id is missing. This should never happen from a payment initiated within Blesta.

        Show
        admin Paul Phillips added a comment - - edited The gateway may also determine which client the payment is set to based on the payer email. Should that behavior no longer occur? If there exists another client account in the system, they could pay as one client and the payment could be applied to another. The client ID is included when a payment is initiated by Blesta so that Blesta knows where to apply the PayPal payment regardless of email as it is included in the IPN call. The issue comes into play when data is imported into Blesta from a competitor and the client has a PayPal Subscription; in this case, client ID does not exist and a match on email is attempted, and the payment is not applied if a match cannot be found. This is a separate issue with a straightforward solution: Subscription ID's. PayPal provides a subscription ID for each subscription. We should really be storing this, and referencing the subscription ID rather than the email for such payments. I created CORE-2367 to deal with this. Edit: To answer your question, we should not change the behavior if email match is only performed when client id is missing. This should never happen from a payment initiated within Blesta.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              15/Jun/18

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 hour, 22 minutes
              1h 22m

                Agile