eSuite v160.0

Enabling Existing Recurring Service Type Features for Bundle Service Type

A small but meaningful piece of development enabling clients to configure Bundle Service types with more flexibility by exposing existing service features against this new service type, with a primary focus on enabling customers to re-subscribe. This includes:

1. Via REST API, clients can now re-subscribe to a pre-defined or user-defined bundle (Bundle Service Type) they previously had. Changes can be made against the following endpoint:  POST /api/accounts/accountReference/subscriptions*
2. Via eSuite HQ, clients can now reactivate a bundled subscription service type via the 're-subscribe' button in the account subscriptions tab*
3. Via eSuite HQ, clients can now define 'lock-in periods' against a bundle subscription service type. This means that any attempt to 'cancel instantly' via eSuite HQ or via API is prohibited during that period

*Re-subscribe logic works on the following events:

1. The subscription is re-activated
2. The subscription status is set to active
3. Auto-renew status is set based on the configuration of the service (period, number of auto-renewals)
4. Any trial period which applied to the original subscription is lost
5. The Low Start Offer which applied to the original subscription is not applied, even if the subscription is still within the applicable period
6. The subscription has the same cart as before the cancellation
7. The re-subscription will not be allowed if the existing subscription to the bundle is in one of the following states: Active, Failure Retry Mode, Subscription Pending Start Date & On Holiday
8. A new record will be added to the Customer Support Log

Delivery Calendar

Earlier this year, we announced an extensive feature set to support physical subscriptions. A key aspect of being able to offer physical subscription capability is the delivery of goods, such as newspapers or a subscription box, to a customer's delivery address. A common use case of supporting the delivery, is the ability to change addresses, either permanently or temporarily. For example if a customer moves house, they would require a permanent address change. On the other hand, other customers may only require a temporary change of address.

To support these types of use cases, we have have developed a solution which enables customers to define their own Delivery Calendar. A summary of key features include:

1. Defining delivery addresses & notes - Customer Support Agents now have the capability to change a delivery address and specify a date for which the change should take effect within the Account Subscriptions tab. Delivery notes can also be applied against the overall subscription within the Account Subscription and against each individual fulfillment within Orders.  End-Customers will also be able to specify and configure this information themselves within self-care pages using eSuite API and eSuite SDK.
2. Defining delivery patterns - An optional feature which can be defined by both Customer Support Agents and End-Customers to specify which address to deliver to for specific days of the week. For example, during the week a customer may want their newspaper delivered to their work office, and at the weekend, delivered to their home address.
3. Defining redirection or stop orders - Customer Support Agents and End-Customers can now configure temporary changes to a set of deliveries; be this to stop all deliveries for x period, or to redirect to a temporary address (be this a pre-defined address against the account or new). The feature allows for a start & end date and an address to be specified, as well as a 'stop indicator' to halt all deliveries. The ability to edit an existing redirection/stop order is also available.

Delivery Calendar will be available on v11.1 of the REST API and version 5.0 of eSuite SDK.

Release Service Pack

• Purchase calls will no longer be delayed receipt while sending out a receipt email
• All ADDACS (Automated Direct Debit Amendment and Cancellation Service​) "Reactivate account" notifications will process as expected
• Additional logging to aid investigations should refunds fail
• Move Subscription API has been altered to ensure multiple renewals/charges will never occur on the odd occasion
• Improved validation of user input in Offer Management
• Specific Direct Debit orders will no longer be excluded from the Filterable orders data feed
• Calling the GET session (/api/sessions) endpoint will no longer throw a 500 error a specific set of use cases
• If Google Play (Native Billing) extends access to a subscription due to a payment error, a new order will not be generated and will go into retry mode
• The Detailed Transaction Report will now correctly display bulk order summaries
• Improved logging of activity when suspending 2FA for an account
• Added the ability for an administrator to reactivate 2FA for an account
• Improved performance when searching for accounts in eSuite HQ
• Changing the status of an account is now reflected immediately in eSuite HQ
• The flow for moving subscriptions in a parent/child scenario now mirrors that of a non parent/child setup
• Added validation to to prevent non-latin characters being used for Entitlement Identifiers
• Move subscription no longer displays previously subscribed subscriptions in the 'available' list
• Changed order of First Name and Last Name fields in Virtual Terminal for Japanese language users