If credit card payment is declined for membership product, user account is still assigned the DNN security role.

[parasdaryanani]

Describe the bug

When purchasing a membership type product and payment is declined, the user account is still assigned the DNN security role.

Software Versions

• DNN: 08.03.00
• Hotcakes: 03.02.01

To Reproduce

Steps to reproduce the behavior:

1. Setup a Demo Hotcakes Store
2. Configure the Payment Methods to be:

• Credit Card - Authorize.NET in Developer Mode
• Charge full amount on ordering
• Require CVV code

3. Create a new Security Role called "Testmember"
4. Create a new membership product type called Testmember subscription
5. Create a new product called Testmember and assign the Testmember subscription type which was created in the previous step.
6. Go to the store and add the Testmember item to the cart
7. Click Secure Checkout
8. Fill out the shipping address. In the ZIP CODE field put in 46282 (This tells Authorize.NET to treat this as a declined credit card purchase)
9. Use credit card number 4111111111111111 with any expiration date in the future and any 3 digits for the CVV code.

Expected behavior

The order should be created in Hotcakes and marked as unpaid. The user should be directed to the Checkout/action/paymenterror page to be prompted to update their billing address and payment details. The Testmember security role should NOT YET be assigned to the customer user account, until after they have paid.

Actual behavior

The order is created in Hotcakes and marked as unpaid. The user is redirected to the Checkout/action/paymenterror page and prompted to update their billing address and payment details. The Testmember role is automatically assigned to the customer user account. The customer receives a DNN email confirming that the role has been assigned.

[parasdaryanani]

It seems this is because the MembershipTask() runs within the LoadProcessNewOrderTasks() workflow. This workflow runs when the order is moved from 'New' to 'TODO' state.

In DnnWorkflowFactory.cs:

protected override Task[] LoadProcessNewOrderTasks()
        {
            return new Task[]
            {
                new WorkflowNote("Starting Process Order Workflow"),
                new UpdateOrder(),
                new CheckForZeroDollarOrders(),
                new DnnCreateUserAccountForNewCustomer(),
                new AssignOrderToUser(),
                new AssignOrderNumber(),
                new MakeOrderAddressUsersCurrentAddress(),
                new AddUserAddressesToAddressBook(),
                new UpdateLineItemsForSave(),
                new UpdateOrder(),
                new DnnMakePlacedOrder(),
                new WorkflowNote("Finished Process Order Workflow"),
                new UpdateOrder(),

                // Added to handle "membership" products
                new MembershipTask()
            };
        }

Moving the MembershipTask() to run within the LoadProcessNewOrderAfterPaymentsTasks() workflow would make more sense, since the latter is the workflow that runs after successful payment is applied.

Adding an override to DnnWorkflowFactory.cs for the LoadProcessNewOrderAfterPaymentsTasks() and removing MembershipTask() from LoadProcessNewOrderTasks() fixes the issue, as shown below.

protected override Task[] LoadProcessNewOrderTasks()
        {
            return new Task[]
            {
                new WorkflowNote("Starting Process Order Workflow"),
                new UpdateOrder(),
                new CheckForZeroDollarOrders(),
                new DnnCreateUserAccountForNewCustomer(),
                new AssignOrderToUser(),
                new AssignOrderNumber(),
                new MakeOrderAddressUsersCurrentAddress(),
                new AddUserAddressesToAddressBook(),
                new UpdateLineItemsForSave(),
                new UpdateOrder(),
                new DnnMakePlacedOrder(),
                new WorkflowNote("Finished Process Order Workflow"),
                new UpdateOrder()
            };
        }

protected override Task[] LoadProcessNewOrderAfterPaymentsTasks()
        {
            return new Task[]
            {
                new WorkflowNote("Starting Order After Payment Workflow"),
                new UpdateOrder(),
                new LocalFraudCheck(),
                new MarkCompletedWhenShippedAndPaid(),
                new EmailOrder("Customer"),
                new EmailOrder("Admin"),
                new MembershipTask(),
                new WorkflowNote("Finished Order After Payment Workflow"),
                new UpdateOrder()
            };
        }

I'd be happy to create a pull request if you agree.

[WillStrohl]

This looks good. I agree. :)

If you can get it done within the next few weeks, I'll push this into the 03.02.02 milestone.

Thanks!

[WillStrohl]

Can you please create a pull request when you're ready? :)

[parasdaryanani]

@hismightiness all done, please refer to #192 :)

[WillStrohl]

TO-DO

• Update documentation
• Update workflow development sample project

[WillStrohl]

I just tested this update and now a membership product is assigned upon authorization. So, the customer gets assigned before the funds are actually captured. Membership-based stores are probably less likely to be configured this way, but that is still a problem.

This has otherwise tested to resolve the issue described here.