Release Objectives
The primary objectives for the Cobalt 3.9 Release were to:
- Expand our eCommerce functionality to close the gap on our competitors so that we can reduce the cost of our implementations and win more deals.
- Increase the number of payment options that our clients can offer to their customers to reduce the friction related to completing transactions.
- Add new features that optimize the portal checkout process to improve the user experience and to allow our clients to upsell membership more effectively.
- Create a process that allows our clients to report and act upon abandoned orders.
Expected Benefits
The Cobalt 3.9 release will be considered a success if the following criteria are met.
- We support both payment plans and auto-renewals for Authorize.net so that customers can offer these options OOTB.
- ACH can be configured as an additional payment method on the portal with Authorize.NET.
- Contacts or other individuals at an organization (i.e. accounts payable staff that do not have a login) can pay for an order on the portal by using a specific link that does not require you to log into the portal.
- Portal users can save a credit card to their portal profile for later use with Authorize.NET.
- Staff can upsell membership when a non-member is checking out on the portal and grant member pricing for the entire transaction when a membership application is added to the shopping cart.
- Staff can configure a report that shows orders that were started on the portal but were never completed.
- Please note we are encouraging clients to use Google Analytics for this report. We have created a recommended setup guide, along with example reports. Please reach out to the Product team for more information.
- Staff can send emails based on abandoned orders to encourage order completion.
Supported CRM Versions
D365 On-Premises
- 8.X Version: 8.2.28.11 (April 2021). This is the most recent version of 8.2 and we do not expect any future updates because the end of mainstream support for this version was January 12, 2021.
- 9.X Version: Not Supported. We are not supporting 9.0 on-prem because it is no longer supported by Microsoft. We plan on supporting 9.1 on-prem with a minor version release.
D365 Online
We continue to support the latest version of Dynamics 365 Online with the 3.8 release. Note that regression testing was completed on the server version 9.2.22064.00202, but these builds often vary based on the region the customer’s tenant is located in. For implementations or projects that are targeting an online go-live, it is best to patch any on-premises D365 (i.e. dev and/or stage) to the latest 9.x version as to have the smallest version gap between what is on-premises and what is online.
Cases and Background
Universal Shopping Cart
A large part of this release was implementing a universal shopping cart. This new experience allows portal users to register for a meeting, class, etc with a single transaction. Instead of completing individual, straight-line processes, contacts can now add items to their cart and pay for these items using the streamlined check-out experience. The order is associated with a cart entity using a N:1 relationship.
When a contact adds an item to their cart, the order and related wizard item (meeting registration, class registration, etc) is created, but is not submitted. Once an item is in the cart, a contact can edit that item or remove the item.
The item and related order exist in CRM in this working state until one of three things happen:
- The contact pays for the item. This will submit both the wizard item and the order.
- The contact manually removes the item from their cart. This will roll back both the order and the wizard item.
- The contact logs into the portal and they are no longer eligible for an item in their cart that they previously added. This will invoke the same roll back functionality as manually removing the item from the cart.
Please note we also updated the coupon logic for the universal shopping cart. If a contact is using a single product coupon and they have multiple orders in their cart with that same product, the coupon will only apply to a single order. If the contact is using a all product coupon and they have multiple orders in their cart, the coupon will apply to all orders. If a contact is using an order – percentage off coupon, the coupon will apply to all orders in the cart.
Portal Facing Features
| Case | Title | Description |
| 39327 | Universal Checkout – Framework – Wizard Skeleton | This case repurposed the existing online store wizard pages to now be used for the new cart process. As the portal user gets funneled into these pages from the individual modules, orders are associated with the cart entity. |
| 39328 | Universal Checkout – Framework – Configuration – Initial Imp | This case created the service configuration that allows organizations to enable the universal shopping cart. This allows current customers to upgrade to Cobalt 3.9 without potentially needing to completely overhaul custom code that has already been built around the existing processes. Please note that while this is configurable, we recommend organizations decide if they would like to take advantage of this new feature at the beginning of the upgrade/implementation and stick with the decision. |
| 39329 | Universal Checkout – Framework – Configuration – Core | This case reworked the flow so that if universal check out is enabled, contacts who are submitting a meeting registration, class registration, subscription, or custom eCommerce type are prompted to add these items to their cart instead of checking out within the straight line process. Then, they are sent through the universal check out flow. |
| 39332 | Universal Checkout – Framework – Cart.aspx Display (Core) | This case determined the display logic in the universal shopping cart for web elements, meeting registrations, class registrations, and publication subscriptions. |
| 39333 | Universal Checkout – Framework – “My Orders” Update | If Universal Checkout is enabled, a ‘View Cart’ link will appear next to a wizard item on the ‘My Orders’ page (as opposed to the URL generated via the order source that shows Submit Application, Pay Dues, etc) |
| 39337 | Universal Checkout – Framework – Shipping.aspx | If a product is shippable, the universal checkout process will show the /Sales/Catalog/Payment/Shipping.aspx page where portal users can enter in shipping information. This shipping information will then be mapped back to the applicable order. |
| 39341 | Universal Checkout – Framework – Cart.aspx Edit | This case updated the cart page so an ‘Edit’ button appears for each wizard item in the cart with the correct order source configuration. If a portal user clicks this ‘Edit’ button, they are taken back to the beginning of that wizard process. |
| 39222 | Universal Checkout – Coupons | This case implemented the logic necessary to apply coupons to multiple orders in the same cart at one time. |
| 40771 | Universal Checkout—Wizardification of Wizard Items—Initial Imp | This case covered the initial implementation for a couple of different features. This case implemented the logic that allows us to save carts between different browsing sessions. This means a portal contact can add something to their cart, log out of the portal, then log back in and pay for those cart items without needing to readd them. This case also created the logic that rolls back the wizard item and order when something is removed from the cart. There were also some more technical updates made in this case around the ‘edit’ functionality and cart context functionality. |
| 39266 | Cart Navigation on Homepage | This case implemented the cart navigation icon on the portal for the universal checkout process. Please note the cart icon only displays when there is something in the cart and the portal user is not already in the universal check out flow (from the cart page to the receipt page). |
| 40728 | Hide Coupon Control on /Meetings/Registration/Information/Summary.aspx when universal shopping cart is enabled | This case hides the coupon control on the meeting summary page when universal checkout is enabled (in favor of the coupon control detailed in case 39222 and XXX). |
| 40846 | Remove coupon control on /Subscriptions/OrderSummary.aspx when universalcheckout is enabled | This case hides the coupon control on the subscription order summary page when universal checkout is enabled (in favor of the coupon control detailed in case 39222 and XXX). |
| 40698 | Meeting Registration Edit / Remove Functionality | This case updates the edit and delete functionality for meeting registrations in the universal cart so that each meeting registration is its own wizard item. If you edit a meeting registration, you will be taken to a meeting registration sub-wizard just for that attendee. If you remove a meeting registration from the cart, it will remove just that single registration. |
| 40665 | Add Registrant Name to Universal shopping cart for meetings | This case added the registrant’s name to the meeting registration items in the cart so portal users will know which contact the registration is tied to. |
| 40772 | Universal Checkout—Wizardification of Wizard Items—Core | This case implemented the logic from case 40771 for class registrations, meeting registrations, publication subscriptions, and custom eCommerce types. |
| 40628 | Revamp order cart order summary + submission + receipt page | This is the case where we designed the new universal cart page, submission page, and receipt page. |
| 40938 | Cart Coupon UX/UI Updates | This case updated the UI of coupons in the universal cart and added helpful validation messages when a coupon code is entered but is invalid because it is expired, etc. |
| 41259 | Custom eCommerce and Subscription Cart Icon | This case updated the eCommerce and subscription cart items to use the list image on the product instead of a default icon. |
| 41224 | Cart Restart – Item Eligibility Evaluation – Initial Imp | This case covered the initial implementation of checking that items in a cart are still valid upon logging into the portal for the portal user. If that item is no longer valid, it is removed from the cart. |
| 41223 | Cart Restart – Item Eligibility Evaluation – Core | This case implemented the item eligibility logic from case 41224 for class registrations, meeting registrations, publication subscriptions, and custom eCommerce types. An example of the impact of this case is if a contact adds an early bird fee for a meeting to their cart, and then they log out of the portal and log back in a couple of days later, the meeting registration will be removed from the cart. |
| 41132 | Need to display orders with a payment plan connected to them on /Sales/Orders.aspx | This case updates the ‘My Orders’ page to show orders with active payment plans. |
| 40828 | Rename ‘Shop’ tab when Universal Checkout is Enabled | This case renamed the ‘Shop’ tab to read ‘Store’ when universal checkout is enabled. |
| 41184 | Product (Single) Percentage / Amount Coupon Issues in Universal Shopping Cart | This case updated coupon logic for the universal check out process. If a contact is using a single product coupon and they have multiple orders in their cart with that same product, the coupon will only apply to a single order. If the contact is using a all product coupon and they have multiple orders in their cart, the coupon will apply to all orders. |
| 40617 | /Sales/Catalog/ProductSearch.aspx shows only store products in shopping cart | This case updated the Product page for the online store to no longer include the store products. Instead, you see a link that takes you to your cart. |
Back End Logic
| Case | Title | Description |
| 39317 | Universal Checkout – Remove Wizard Item – Customizations | This case added the ability to configure the text that pops up on the portal confirming you want to remove an item from your cart. Please note this originally also added a cart cleanup URL that we later deprecated. |
| 39326 | Universal Checkout – Framework – Customizations | This case created the new ‘Cart’ entity that allows us to track a “cart” from one browser session to the next for the same individual. This case also created a relationship between orders and a cart. |
| 39334 | Universal Checkout – Framework – Plugin | If an order that was associated with a cart is reopened (most likely because the payment needs to be refunded or unapplied), we will clear out the cart lookup on the order. |
| 39339 | Universal Checkout – Framework – Submission.aspx | This case updated the submission page for the universal cart so that upon submission, a single payment record is created and multiple sales order payments are created for each order in the cart. This deactivates the cart record in CRM. |
| 40734 | Disable Cart for ISV | This case disabled the universal cart in the ISV, even when it is enabled in the portal. |
| 41028 | Universal Checkout Receipt HTML Updates for Email Compatibility | This case updated our email receipts for the universal checkout process. |
Universal Shopping Cart – Membership
The universal shopping cart functionality that was implemented in this release allows us to upsell membership to portal users who are not a member of an organization, but are using the portal to register for a meeting, class, etc. If a non-member is checking out, they will now see a configurable message on the cart page prompting them to apply for membership. Once the contact has a membership application in their cart, the price of the other items will recalculate to use the member pricing. If a contact is already a member and they are checking out, they will see a new message on the cart page showing how much money they saved by being a member. Please note the membership upsell functionality is only available for contact based membership models.
Please note membership applications are the only item that is submitted upon adding it to the cart (as opposed to when it is paid), so organizations should use the ‘Order Paid’ requirement to prevent these applications from being completed without payment. This was already a best practice, but the Product team wants to re-emphasize the importance of this requirement.
Portal Facing Features
| Case | Title | Description |
| 39342 | Universal Checkout – Framework – Cart.aspx Display (Membership) | This case determined the information for membership applications and dues items that display in the universal shopping cart. |
| 39331 | Universal Checkout – Framework – Configuration – Membership | This case reworked the flow so that if universal check out is enabled, contacts who are submitting a membership application or a dues item payment are prompted to add these items to their cart instead of submitting the application or dues renewal within the straight line process. Then, they are sent through the universal check out flow. |
| 39190 | Universal Checkout – Membership Upsell | This case implemented the membership upsell process in the universal cart. If a contact is on the cart page and they are not a member of the organization, a message prompting them to become a member to save money will appear. |
| 40626 | Create new page for membership upsell process | This case created a new page for the membership upsell process. This page uses the same logic as the membership tile on the portal, so when a portal user is taken to this new page, they only see fees they are eligible for. We recommend organizations use this page in the alert implemented in case 39190. |
| 40773 | Universal Checkout—Wizardification of Wizard Items—Membership | This case implemented the logic from case 40771 for membership applications and dues renewals. |
| 41225 | Cart Restart – Item Eligibility Evaluation – Certification and Membership | This case implemented the item eligibility logic from case 41224 for membership applications, dues items, initial certification applications, and continuing certification applications. An example of the impact of this case is if a contact adds an early bird dues item to their cart, and then they log out of the portal and log back in a couple of days later, the dues item will be removed from their cart and they will be prompted to move through the renewal process again with a different dues option. |
| 40627 | Add a membership + post membership application process message on universal cart page to show savings | This case implemented a savings message on the universal cart page. This message will appear if the contact checking out has a price list that is not the current price list (e.g. they are a member) or if the contact checking out has a membership application in their cart, and therefore is receiving member pricing. This configurable message calculates the amount saved by becoming/being a member. |
Universal Shopping Cart – Certification
We implemented the universal checkout process functionality for certification processes as well. The logic follows the same logic implemented for core processes noted above.
Portal Facing Features
| Case | Title | Description |
| 39343 | Universal Checkout – Framework – Cart.aspx Display (Certification) | This case determined the information for initial certification applications and continuing certification applications that displays in the universal shopping cart. |
| 39330 | Universal Checkout – Framework – Configuration – Certification | This case reworked the flow so that if universal check out is enabled, contacts who are submitting an initial certification application or a continuing certification application are prompted to add the applications to their cart instead of submitting the applications within the straight line process. Then, they are sent through the universal check out flow. |
| 40774 | Universal Checkout—Wizardification of Wizard Items—Certification | This case implemented the logic from case 40771 for both initial and continuing certification applications. |
Auto-Renewal
This release implemented auto-renewal functionality for membership. If allowed by the organization, portal users can opt into auto-renewal when they are applying for membership or when they are renewing their dues. When a contact opts into auto-renew, they will be forced to either use an existing saved payment profile or create a new one. The date of enrollment and the payment profile will then be set on the membership record. The next time a dues renewal order is generated, we will kick off the auto-renewal process.
We are using queried cron jobs to send auto-renewal reminders, so the logic around when organizations want to send these reminders is configurable. However, we recommend sending a reminder a few weeks in advance of the membership expiration. This will set the reminder date on the dues item. Then, we recommend setting up another queried cron job that will set the ready for auto-renewal field to yes on the dues item a few days after the reminder is sent out. Finally, there is another cron job that will send the dues item orders that are ready for auto-renewal to the payment service. The payment service will charge the card on file, and send those payment records back to CRM.
The recommended queried cron job configuration is detailed in the implementation notes.
Please note contacts can opt-out of auto-renewal at anytime after enrollment. Contacts can also supersede the auto-renewal functionality by manually renewing their membership on the portal, but throughout the process, they will be alerted that they are already enrolled in auto-renewal and manual checkout is not necessary.
Auto-renewal is only available with Authorize.NET.
Portal Facing Features
| Case | Title | Description |
| 37695 | Enroll in Auto Renewal: Membership Application | This case implemented the auto-renewal flow on the portal during the membership application process. Upon submission of a membership application that is enrolled in auto-renewal, it will also set the appropriate fields on the related entities in the back end. |
| 37696 | Enroll in Auto Renewal: Dues Renewal | This case implemented the auto-renewal flow on the portal during the dues renewal process. Upon submission of a dues payment where the contact opted to enroll in auto-renewal for next time, it will also set the appropriate fields on the related entities in the back end. Please note because we are implicitly creating a payment profile if the contact does not opt to use an existing one, the payment processor must allow for payment profiles. |
| 37697 | Enroll in Auto Renewal: Enrollment Warning | This case adds a message to the dues renewal process on the portal that alerts the contact if they are paying for a dues item that is already enrolled in auto-renewal. It also prevents payment in the case that a dues item enrolled in auto-renewal has a pending sales order related to it. This is to cover the scenario in which the system was able to process a charge but was not able to apply it due to a configuration issue. |
| 37665 | Unenroll in Auto Renewal | This case enables a portal user to unenroll in auto-renewal. Please note the display text is configurable via the Web Element Designer. |
| 39161 | Enroll in Auto Renewal – Separate Page | This case implemented the new ‘Enroll in Auto-Renewal’ page on the portal. |
| 41310 | Update Auto-Renewal Validation Logic | This case implemented the validation logic that forces you to either use an existing saved payment profile or save a new payment profile when you have opted into auto-renewal. |
| 41080 | Update auto-renew logic now that universal shopping cart is enabled | This case did some additional work around auto-enrollment logic. |
Back End Logic
| Case | Title | Description |
| 37658 | Auto Renewal – Schema Updates | This case implemented the necessary back-end customizations on the membership, member type, dues item, and settings record to make the auto-renewal process possible. |
| 37660 | Auto Renewal Reminders Cron | This configuration case created two workflows within the solution: one that sends the auto-renewal reminder and updates the dues item with the reminder date, and another that sets the dues item to ready for auto-renewal. These workflows work in tandem with queried cron jobs, which must be set up on an environment-by-environment basis. |
| 37661 | Auto Renewal Payment Profile Charge Cron | This case provisioned the cron message “AutoRenewalMembership” that actually charges payment for dues items that are ready for auto-renewal payment. |
| 41379 | Hide option to enroll in Auto-Renewal in Membership Application Wizard ISV | This case hid the option to enroll in auto-renewal in the membership application ISV wizard. |
Payment Plans
This release introduced payment plans for membership applications and dues renewals. Portal users can use either a credit card or ACH profile to enroll in a payment plan. Payment plan options are connected to dues options, so payment plans are only available for membership applications if that membership application fee has a dues option set and that dues option has related payment plan options. Organizations have the ability to configure if a dues product should be split between all of the payment plan payments or if it should be included in the first payment. We imagine the first option will be used for traditional dues products, and the latter will be used for optional products (ex: PAC contributions). However, membership application fee products will always be included in the first payment.
Payment plan charges will not begin before a membership cycle begins and will not extend past a membership expiration date. For example, if an organization is taking advantage of our dues proration functionality and a portal user applies for membership halfway through the year of a Jan 1 2022 – Jan 1 2023 membership cycle using a monthly payment plan, we will split the applicable total between the remaining monthly payments in that cycle.
When a portal user enrolls in a payment plan, we create the payment plan record in CRM and send the information about the plan to Authorize.NET. Once Authorize.NET receives that information, they create a subscription with a unique subscription ID. We completely offload the actual recurring charging to Authorize.NET. However, we store that subscription ID on the payment plan record in CRM, and query Authorize.NET on a scheduled basis to look for completed payment plan charges. When a new completed payment is identified in Authorize.NET, it is set on the payment plan charge record in CRM and is applied to the invoice. Please note any ‘Order Paid’ requirements will be fulfilled when a contact enrolls in a payment plan and a dues item will have the ‘Date Paid’ populated when a contact enrolls in a payment plan. However, the order and invoice will not be completed until the invoice is actually paid off.
There are a couple of known limitations with payment plans. These are listed below.
- Payment plans are only available with authorize.NET.
- Authorize.NET takes a couple of days to charge recurring payments. The ‘due at checkout’ on the portal indicates a payment plan that begins today will also be charged today, but it will actually take a day or two for that payment to appear on the portal user’s statement and for that completed charge to be sent to CRM.
- Organizations can leverage payment plans and auto-renewal functionality at the same time, but individual contacts cannot enroll in auto-renewal if they are already using a payment plan for the current membership order.
- Payment details (last four digits of card, expiration date, etc) will not display on the receipt page if you are only paying for an order that is enrolled in a payment plan. If this information is important for organizations, we recommend they work with our implementation teams to retrieve that information.
Portal Facing Features
| Case | Title | Description |
| 36461 | Payment Plan: Membership Application | This case enables the ability to configure payment plans for membership applications when the universal checkout process is disabled. |
| 36465 | Payment Plan: Dues | This case enables the ability to configure payment plans for dues items when the universal checkout process is disabled. |
| 36466 | Create CC Payment Plan: Authorize.NET | This case updated our authorize.NET integration to allow for the provisioning of a subscription (e.g. a payment plan). |
| 39188 | Payment Plan: Universal Checkout | This case implemented the ability to configure payment plans for membership items when universal check out is enabled. It also updated the cart page with a ‘Due at Checkout’ amount that displays the total amount of non-payment plan items in a cart, along with the first payment of the payment plan if applicable. |
| 39313 | Auto Enrollment Suppression w/ Payment Plan | This case suppresses the auto-enrollment page on the portal when a contact is opting to use a payment plan. Please note the ability to use both a payment plan and enroll in auto-renewal at the same time is not supported in this release. |
| 36471 | View Payment Plans and Upcoming Charges | This case implemented a navigation item to the site map under the “My Orders” item called “Upcoming Charges.” This directs the portal user to /Profile/UpcomingCharges.aspx, which shows active payment plans for that contact, along with the pending charges related to those payment plans. |
| 39205 | Create CC Payment Plan via Saved Payment Profile: Authorize.NET | This case updated our authorize.NET integration so that we can provision a payment plan from an existing payment profile. |
| 40939 | Cart Payment Plan UX/UI Updates | This case updates the universal cart process to include a due at checkout line within specific wizard items if applicable, and also updates the submission and receipt pages to show the specific payment schedule for payment plans. |
Back End Logic
| Case | Title | Description |
| 39497 | Payment Plan: Customization Updates | This case deprecated superfluous fields for both payment plans and payment plan options. It also added new fields for these entities, plus the payment plan interval entity, that enables us to connect a payment plan to a payment service (i.e. authorize.NET). |
| 39498 | Payment Plan: Processor Updates | This case implemented the logic for creating payment plans in CRM and the way authorize.NET communicates with that information. A pending payment plan is created for the contact in CRM, and once that information has been sent to authorize.NET and verified, the payment plan then becomes active. This case also sets the Plan ID on the payment plan entity, which we get from authorize.NET. Please note in authorize.NET, this is called the subscription ID. |
| 40672 | Payment plans should not extend membership expiration date | This case implemented the logic around payment plan begin and end dates. Payment plan begin and end dates are “confined” to the membership begin and end dates. This means if you are applying for a membership application on July 1st, 2022 with a monthly payment plan and the membership cycle ends on January 1st, 2023, the order total will be distributed among the six remaining payments. This also means if you are renewing a membership early, the first payment will not be charged until the membership begins. |
| 40674 | Update ‘Date Paid’ and ‘Order Paid’ logic for payment plans | This case updated the logic around the ‘Date Paid’ logic for dues items so that if someone uses a payment plan to pay for a dues item, the ‘Has Pending Payment’ field on the sales order payment entity gets set to ‘Yes,’ which then sets the dues item date paid field to today’s date. We also updated the queriedcronjob query that fulfills the ‘Order Paid’ requirement to include has pending payment = yes. Please note this is just a configuration change. |
| 36468 | Cron Payment Plan Processing | This case updated an existing cron so that we can inquire to external payment services about the status of a payment plan charge. The payment service is responsible for charging the card/ACH profile, but we pull that information into CRM. Assuming the charge is successful, if this is the first charge in the plan, we will create the invoice, create the payment, apply the payment to the invoice, and then mark the charge as succeeded. If a successful charge comes through and it is not the first payment plan charge, we will update the existing invoice, create the payment, apply the payment to that existing invoice, and then mark the charge as succeeded. Please note that if today’s date is past the scheduled charge date and the recurring charge failed grace period set on the Settings record, we will mark the scheduled charge as failed. |
| 40764 | Create a payment plan from an ACH payment | This case allows portal contacts to use an ACH payment type for payment plans. |
| 40754 | Make dues product + membership application fee product split for payment plans configurable | This case created the logic that determines how a membership application/dues renewal order that is paid for via a payment plan gets split up. Please note a membership application fee product will always be included in the first payment. This is not configurable. However, dues products (if the option is tied to a membership application or it is a stand alone option for renewal) can be configured to be charged in either the first payment, or split among all of the payments. |
Payment Profiles
This release added the ability for portal users to save either a credit card or ACH account to their profile. Portal users can then use these saved payment methods when checking out in the future. Portal users can also edit and remove saved payment profiles via the self-service tools provided on the portal.
Payment profiles are only available with Authorize.NET.
Portal Facing Features
| Case | Title | Description |
| 36455 | Authorize.NET: Create Individual Payment Profile | This case enables portal users to save a card to their profile for future use with authorize.NET. |
| 36459 | Authorize.NET: Charge Existing Profile | This case enables portal users to check out using a card they previously saved to their profile with Authorize.NET. |
| 36474 | Authorize.NET: Update Existing Payment Profile | This case enables portal users to update an existing authorize.NET payment profile through the ‘Update My Profile’ process on the Cobalt portal. We then send those updates to authorize.NET. |
| 36632 | PayFlow: Create Individual Payment Profile | This case enables portal users to save a card to their profile for future use with PayFlow. |
| 36633 | PayFlow: Update Individual Payment Profile | This case enables portal users to update an existing Payflow payment profile through the ‘Update My Profile’ process on the Cobalt portal. We then send those updates to Payflow. |
| 36634 | PayFlow: Charge Individual Payment Profile | This case enables portal users to check out using a card they previously saved to their profile with Payflow. |
| 36477 | Update UI/UX of Managing Payment Profiles via Profile Update | This case updated the portal UI to allow for updating existing payment profiles and adding new ones via the ‘Update My Profile’ process. |
| 39324 | ACH Payment Profiles – Sales Transaction | This case updated our authorize.NET integration to enable portal users to check out with an ACH payment profile, both when using a new and existing profile. |
| 39325 | ACH Payment Profiles – Profile Updates | This case enables portal users to create and update an ACH payment profile via the ‘Update My Profile’ process on the Cobalt portal. |
| 39323 | ACH Payment Profiles – UX/UI | This case updated the UX/UI of our payment controls to allow a user to check out with an existing ACH payment profile or create a new one. |
Back End Logic
| Case | Title | Description |
| 36454 | Recurring Payment Profile Schema Updates | This case updates the entity fields in the back end to have a look up to the payment service on the payment profile record (so you can have payment plans tied to different services) and adds a lookup field to the payment entity that looks up to a payment plan (so staff members will know if a payment profile was used). |
| 36456 | Recurring Payment Profile to Payment Service Tracking | This case sets the payment service on the payment profile when created. |
| 36464 | Record Charged Payment Profile on Payment for Adhoc Charges | This case sets the payment profile on the payment record when a payment profile was used. |
| 39322 | ACH Payment Profiles – Customizations | This case added the appropriate customizations to the ‘Payment Profile’ entity to allow for ACH payment profiles. |
eCommerce Improvements
This release implemented the ability for organizations to accept ACH payments without needing any custom code. Please note ACH payments are only available with Authorize.NET.
One thing to be mindful of Authorize.NET has implemented measures with ACH payments to ensure duplicate charges do not happen accidentally. As a result, portal users will see an error if they try to check out using the ACH payment method for orders that have the same total amount throughout the day.
Portal Facing Features
| Case | Title | Description |
| 36651 | Investigate Online Store Load Time | This case investigated some of the slowness we have seen when using the online store and improved query load time. |
| 37687 | Payment UX/UI Updates for ACH: Initial Imp | This case is the initial implementation of using an ACH payment type on the portal and that information getting mapped back to the payment record correctly. |
| 37688 | Payment UX/UI Updates for ACH: Core Wide Imp | The case implemented the ability to use an ACH payment type on the portal at the core level (classes, meetings, online store, web elements, subscriptions). |
| 37691 | Payment UX/UI Updates for ACH: Membership Imp | The case implemented the ability to use an ACH payment type on the portal at the membership level (membership applications and dues items). |
| 37690 | Payment UX/UI Updates for ACH: Certification Imp | The case implemented the ability to use an ACH payment type on the portal at the certification level (initial certification applications and continuing certification applications). |
| 40747 | Update /Sales/OrderDetails.aspx to reflect ACH payment type | This case updated the /Sales/OrderDetails.aspx page to include ACH payment details when an ACH payment method was used. |
Back End Logic
| Case | Title | Description |
| 36434 | Update Authorize.Net Assembly reference | This case updated our Authorize.NET SDK reference to leverage the latest version. |
| 36436 | Update Payflow Assembly reference | This case updated our Payflow SDK reference to leverage the latest version. |
| 36624 | Customer Identifiers for Payment Integrations (and beyond) | This case created two new auto-number definitions on the settings record (one for contacts and one for accounts). We now use these auto-numbers to populate a customer number on contacts and accounts. |
| 36625 | Payment Processor Rework | This case refactored our payment processor logic to be payment type centric (instead of credit card centric). |
| 36620/36623 | Cron ACH Inquiry | This case provisioned a cron message to inquire to authorize.net about the status of an ACH payment. We also created a service configuration property on the payment service to indicate how long the system should wait before an ACH payment that has not been rejected/approved should be set to an “Unknown” status. Finally, this sets a settlement date on the payment record once the status has been updated. |
| 36621 | Authorize.NET: ACH Sales Charge | This case implemented the ability for our authorize.NET payment service to be able to process ACH payments. |
| 36638 | ACH Schema Updates | This case made the necessary configuration updates on the payment record to account for ACH payments. |
| 36644 | Process Payment Wizard ACH Update | This case allows for ACH payment via the process payment wizard in the back end. |
| 36645 | Refunds for ACH (Authorize.NET) | This case updated the payment wizard to allow for a “void” option to void ACH payments that had not been settled. |
Misc Improvements
One much-requested feature is included in this release is the ability to pay for an order without logging in. Portal users still need to log in to register for meetings, classes, etc, but if the order is already generated (as it is with the dues renewal process), organizations can either send out the public URL to pay for an order via email or an individual can go into their portal profile, retrieve the public URL, and send that to someone else for payment (most likely someone in an accounting role).
Portal Facing Features
| Case | Title | Description |
| 37684 | Anonymous Order Payment: Wizard | This case created the portal facing process for the anonymous order payment wizard. This allows someone to pay for an order without being logged in. If you have a check out URL (from either case 37683 or 37685), you can enter in that link to be taken through this wizard. |
| 37685 | Anonymous Order Payment: Portal User Link Generation | This case enables a “Send Email” button on the /Sales/OrderDetails.aspx portal page via a service configuration. Portal users can click this button, and a mailto: pop up will populate with a checkout URL that they then send via the default email client. |
Back End Logic
| Case | Title | Description |
| 37683 | Anonymous Order Payment: Customization and Plugin | This case implemented both the plugin that generates the anonymous check out URL and the field itself on the order record that contains the URL. Please note this URL is generated by a workflow that is in the solution that calls the plugin. |
| 40874 | Plugin Adapter Attempts to Retrieve Target Entity Resulting in Infinite Loop | This case fixed an issue from Cobalt 3.8 that caused issues running a workflow that tried to update an order on CRM version 8.2. |
| 41045 | Plugin Adapter Attempts to Retrieve Target Entity Resulting in Infinite Loop (Dues Item) | This case fixed an issue from Cobalt 3.8 that caused issues running a workflow that tried to update an order from a related entity on CRM version 8.2. |
| 42523 | Product Bundle Rounding Fix | This case corrected an issue where we were creating superfluous canceled GL account entries when using product bundles. Please note this did not fix an existing issue with custom receivables and product bundles. |