Skip to main content

PaymentFlo Glossary

Your quick reference guide to common PaymentFlo terms and functions.

PaymentFlo Glossary

Introduction

This document serves as a comprehensive reference guide to PaymentFlo, detailing its core concepts, system architecture, configuration options and integrations. It is intended for administrators, developers, operations teams and other stakeholders responsible for managing stores, payments, orders, shipments, users and integrations within the PaymentFlo platform.

The documentation is structured to reflect how PaymentFlo is used in practice - starting with foundational entities such as Stores and Orders, and progressing through Payments, Shipments, Users, Global Settings and Custom Integrations. Each section explains key features, available settings and operational workflows, providing both conceptual understanding and practical guidance.

PaymentFlo is designed to support a wide range of e-commerce and fulfillment scenarios, including multi-store setups, multiple payment methods, fraud prevention, warehouse and shipment management, and deep integrations with third-party services. This glossary aims to help users configure these capabilities correctly, understand system behavior and make informed decisions when managing daily operations or implementing new features.

Whether you are onboarding a new client, integrating PaymentFlo with an external platform, or maintaining an existing setup, this document should be used as a reference for understanding how the platform works and how its components interact.

1. Stores

1.1 General Information

A Store is a fundamental entity in PaymentFlo. Every PaymentFlo client can have one or multiple Stores.

Typically, one Store corresponds to one client's website, but in some cases, one website can be connected to several Stores. For example, one Magento website can operate in multiple locations, and if necessary, a separate Store can be created for each location with its own payments and settings.

1.2 Store Types

Each Store must have its Type specified.

Currently, there are two store types in PaymentFlo:

  1. Full - Contains all available gateway functionality.
  2. Shipments Only or 3PL - This store type is created for the clients that don’t want to use PaymentFlo for payment options, but want to process their shipments using a fulfillment agent. It contains functionality solely related to processing shipments. Paid orders are automatically downloaded from the client's website, with shipments created in PaymentFlo.

1.3 Store Engines

Each Store should indicate the Engine that the client uses on their website. Store Engine should be specified when Currently, PaymentFlo supports the following Engines:

  1. Magento
  2. Shopify
  3. Woocommerce
  4. Drupal
  5. Prestashop
  6. Zendesk
  7. Pipedrive

1.4 Store Configuration

This page is available when you try to edit a store on the stores list. It contains engine settings and other settings that should not be available for modification by store owners.

1.4.1 Engine Settings

Settings related to connecting the client's website. They appear on the Store editing page after adding it with the required Engine specified. They must be filled in during the integration of a new client.

1.4.2 Base Configuration

  1. Name - The store name that appears in the store selection menu.
  2. Code - The code name of the store, which should only consist of letters, numbers, and underscores.
  3. Store URL - The website address used to access the API and redirect customers back to the store.
  4. Pay Domain - The domain that will be used for the payment page, to which the customers will be redirected from the store. Usually, a subdomain such as pay.example.com is used.
  5. Engine - See above Store Engines.
  6. Store Type - See above Store Types.
  7. Currency - Used in charts on the Dashboard.
  8. Folder - Used in the store selection menu. If a value is specified, the store will be placed in a tab with this name. It is convenient for grouping stores by a specific type like Dev, Wholesales, etc.
  9. View Code - Used to choose a template that will be applied to the payment pages. If the store does not have its own custom template, then no_brand should be selected. If no value is specified, the template corresponds to the store code.
  10. Order - Sorting stores.
  11. Icon - Used in the store selection menu. A link to the image should be added. Usually, the favicon from the client's website is used.
  12. Timezone - Changes the time zone for all dates in the admin panel, including Visibility Time for payments. PST by default.
  13. Max Allowed Users - Limits the count of users admins can create for the store. Limits don’t affect developer role.
  14. Custom Scripts - The specified code is added to every page in the admin panel for this store. This is for developer use.
  15. Enable External Checkout - This option is enabled for stores that have implemented their own payment page using our API. If this option is enabled, users will be redirected from the "pay" and "success" URLs to the external store's checkout URL.

1.4.3 HTTP Authorization

The login and password must be filled in if access to the store's website is restricted by HTTP Authorisation. Otherwise, Paymonix will not have access to the store and will not be able to function properly. HTTP Authorisation is usually used on test and development sites.

1.4.4 Stamps

Settings related to Stamps Integration (see 4.4).

  1. Is Demo - All requests will be sent to the testing endpoint.
  2. Client ID - This parameter should be provided by Stamps support.
  3. Client Secret - This parameter should be provided by Stamps support.

1.4.5 Payments

Settings related to Payments (see 5 Payments), but with restricted access

  1. Tokenize and, if possible, store customer credentials should be marked to enable the Tokenization feature (see 5.5).
  2. Save Data Checkbox Label. A label for the checkbox that will be shown on the frontend for the customers.

1.4.6 Jotform

Settings for Jotform Integration.

1.4.7 Linnworks

Settings for Linnworks (LW) integration. Currently we only use Linnworks for shipments fulfillment and these settings will affect all shipment functionality (see 4).

  1. Is Wholesale - If this feature is enabled, when creating a shipment and there are FX products in the order that are not available in LW, they will be replaced with FP products.
  2. Location - The warehouse where all shipments will be added.
  3. Source - Any name for custom integration, usually PMX.
  4. Mapping Source - Source name of Channel Integration.
  5. Subsource - Subsource name of Channel Integration.
  6. Order Prefix - Every order created in LW will have id started with this prefix.
  7. Application ID - Custom integration ID.
  8. Application Secret - Custom integration secret code.
  9. Token - Custom integration token.
  10. Compulsory Additions - Contains SKUs separated by comma that will be force-added to each shipment.
  11. Enable White List - If this option is enabled, shipments won’t be created if country code in their shipping address is not whitelisted.
  12. White List - The list of whitelisted country codes.
  13. Enable Sync Stock - Enables Stock Syncronization (see 8.1) feature for the Store.
  14. Enable Warehouse Stock Transfer - Enables an ability to create a Warehouse stock transfer request in LW via PaymentFlo API. Source and destination warehouse names should be specified.
  15. Enable Purchase Orders - Enables an ability to create a Purchase Order in LW via PaymentFlo API. Supplier name and Purchase Order destination location should be specified.

1.4.8 Linnworks Weekly Report

Duplicates functionality on the LW Weekly Report page. Can be removed or merged.

1.5 Store Settings

These settings can be found on the Store Settings page and are available for editing to users with an Admin role.

1.5.1 Common Settings

  1. Store Title - Used only for emails currently.
  2. Phone Number - Used only for emails currently
  3. Lock Order After Failed Payment - If this option is enabled, the customer will not be able to modify the order after it has failed (see 2.4).
  4. Sync Canceled Orders - If this option is enabled, canceling an order in the external store will also result in the cancellation of the order in PaymentFlo.

1.5.2 Mailer

Settings related to sending email messages using email services. If this option is enabled PaymentFlo sends order events (see 9) and data to the email service where they are processed in predefined workflows. In such a case, Store owners can create their own email templates and add custom logic based on order events and order data. They have the flexibility to design and customize email content, as well as incorporate additional logic based on the received order events and order information.

Type of email services. You have 2 options:

  • Drip. https://www.drip.com/ (https://www.drip.com/) For integration instructions, see below;
  • Klaviyo. https://www.klaviyo.com/ (https://www.klaviyo.com/). For Integration instructions ,see below.

1.5.3 Sendgrid

Settings related to Sendgrid integration. It can work in parallel with one of the Mailer integrations, as long as the workflows created for the Mailer integration do not include sending emails. Otherwise, the customer might receive duplicate emails.

If this setting is enabled, the customer will receive emails with the standard template for order events. The email template can be slightly customized by modifying the following settings:

  1. Email Logo - An image that will be displayed on the top of the email.
  2. Main Color - The color of links and buttons used in the template

For integration instructions, see 6.1.6.

1.5.4 Mark zero amount orders as paid

This feature allows for automatically marking orders with a zero amount as paid. The specified payment method will be set to the orders with a zero amount

1.5.5 Payments

Lock Cardholder Name - Cardholder name field is locked for editing by customers. Billing address first and last name are used.

1.5.6 Abandoned Cart

This feature sends emails for orders with New status

  1. Abandoned Email Delays - If specified, abandoned cart emails are sent based on the hour delays. Comma-separated.
  2. Cancel On Last Point - If enabled, order will be canceled at the last hour point.
  3. Enable Coupon For Abandoned Cart - If enabled, an abandoned cart coupon is requested from store and send along with other data.
  4. Send Abandoned Emails On Weekends - If enabled, emails will be postponed to Monday.

1.5.7 Abandoned Failed Orders

This feature sends emails for orders with Failed status

  1. Abandoned Email Delays - If specified, failed order emails are sent based on the hour delays. Comma-separated.
  2. Cancel On Last Point - If enabled, order will be canceled at the last hour point.
  3. Send Abandoned Emails On Weekends - If enabled, emails will be postponed to Monday.

1.5.8 Zendesk

If enabled, Zendesk integration (see 6.1.8) is activated.

1.5.9 Aftership

If enabled, Aftership integration (see 4.5) is activated.

1.5.10 Google Analytics

If enabled, PaymentFlo sends events to Google Analytics on order pending and order paid.

1.5.11 Swell

If enabled, Swell integration (see 7.8) is activated.

1.5.12 Post Affiliant Pro (PAP)

If enabled, PAP integration (see 7.9) is activated. If send 'new_affiliate' event on approve is checked, 'new_affiliate' event is sent using email services on affiliates approving.

1.5.13 Affiliatly

If enabled, Affiliatly integration (see 7.10) is activated.

1.5.14 Dailystory

If enabled, tracking number is sent through SMS using Dailystory (https://www.dailystory.com/) API.

1.5.15 Fraudlabs

If enabled, Fraudlabs integration (see 7.6) is activated.

2. Orders

2.1 General Information

Orders are the second most important entity in PaymentFlo after Stores. Each Order can only be associated with one Store. Orders are created when customers are redirected from an external Store to the payment page.

There are 3 ways to create an order:

  1. By installing plugins in the external Store. In this case, Orders can be created by customers through the checkout process or by administrators in the Store's admin panel.
  2. Using the API endpoint.
  3. In the PaymentFlo admin panel, using the option to create a manual order.

2.2 Order Statuses

  1. New - initial status of any Order.
  2. Fraud Review - Orders moved to fraud review due to fraud review process (see 2.5).
  3. Pending - Orders in which customers have chosen a payment method, but the payment has not yet been confirmed.
  4. Processing - Orders awaiting payment confirmation from the payment provider.
  5. Pay Review - Orders with stuck payments.
  6. Failed - Orders with failed payment (see 2.4).
  7. Paid - Orders with confirmed payment.
  8. Refunded - Orders with refunded payment.
  9. Canceled - canceled Orders for some reason.
  10. Charged Back - Orders with refund initiated by customer.
  11. Chargeback Solved - charged back Orders with resolved conflict. Any charged back Order can be marked as solved manually.
  12. Shipped - Orders that received tracking info from shipping services.
  13. Delivered - delivered Orders that was confirmed by a service like Aftership.

2.3 Manual Orders

This feature allows Store owners to create Orders directly in PaymentFlo, without involving their external Store. These Orders will never be synchronized with the external store. The public ID of such Orders will always end with "-M".

2.4 Failed Orders

An Order can have a "failed" status if the payment fails for some reason. This status allows the customer to go to the payment page and try to make the payment for the order again. The Order can only be marked as "failed" after successfully selecting a payment method.

For M2 engines, failed Orders can be modified by customers. They can return to checkout and add products, change shipping and billing addresses or apply coupons. This option is not available if Lock Order After Failed Payment in Store Settings (see 1.5) is enabled.

2.5 Fraud Review Orders

Fraud review is a feature that allows filtering suspicious Orders. When the system detects a suspicious transaction during the payment process, i.e., when the customer selects a payment method and clicks the "Complete Order" button, the system halts the transaction processing, and the Order status is changed to "Fraud Review".

There are three reasons why PaymentFlo may place an Order into "Fraud Review" status:

  1. If the customer's data resembles the data of one of the banned customers (see 8.2);
  2. If the selected payment method has "Low" or "High" Fraud Level settings and Fraudlabs (see 7.6) has identified the user as suspicious;
  3. The previous customer's Order was marked as "Enable Fraud Monitoring".

Orders sent to Fraud Review need to be manually processed by Store owners on the Fraud Review page (https://paymentflo.io/fraud). When processing Fraud Review Orders, Store owners need to choose one of the following options:

  1. Approve & Process - Approve the transaction in the Fraudlabs service and process the Order. This option is used when the customer instills trust.
  2. Approve & Failed - Approve the transaction in the Fraudlabs service but do not process the order. Instead, change the Order status to "Failed” (see 2.4). This option is used when the customer instills trust, but the Order cannot be processed for some reason (e.g., incorrect credit card information).
  3. Reject & Cancel - Mark the transaction as "Rejected" in the Fraudlabs service and cancel the order. This option is used for suspicious customers with whom you prefer not to engage.
  4. Reject & Failed - Mark the transaction as "Rejected" in the Fraudlabs service and fail the Order. This option is used for suspicious customers but allows them to choose an alternative payment method.
  5. Blacklist & Cancel - Place the customer on the blacklist in the Fraudlabs service and cancel the Order. This option is used for clearly unreliable users who should be placed in fraud review for future transactions.
  6. Reject & Do Nothing - Mark the transaction as "Rejected" in the Fraudlabs service, leaving the Order hanging without any action. This option is used when the customer attempts to bypass fraud protection, prolonging the time before giving the customer a reason to make a new attempt.

3. Users

3.1 General Information

Each store can have an unlimited number of users unless restricted by specific store settings (see 1.5). The capabilities of a user in the admin panel depend on their role. Currently, there are 5 available roles:

  1. Basic User - This is a very basic role that has access to only Orders and Transactions (see 2).
  2. Sales Manager - Same to Basic User, but with access to Shipments (see 4), Fraud Review (see 2.5) and Offline Payments (see 5.6).
  3. Finance Manager - Same to Sales Manager, but with access to Dashboard.
  4. Administrator - Same to Finance Manager, but with access to Store Settings (see 1.5, Users Management, Payment Settings (see 5.3), Currency Rates (see 6.1.2) and Stock Management (see 8.1).
  5. Developer - This role is created for PaymentFlo team members only. This role has access to all PaymentFlo features.

3.2 Create a User

Only users with the roles "Admin" or "Developer" can create new users. To create a new user you need to go to Users → User List → Create User and fill these fields:

  1. Username - Can be used for login. Must be unique
  2. Email - Can be used for login.
  3. Password - Must be unique!
  4. Assign To Store - A list of accessible stores for the user
  5. Role - User’s role (see 3.1). Developers can assign specific permissions to individual users on the editing page.

3.3 Two factor authentication

Enabling two-factor authentication (2FA) is mandatory for all PaymentFlo users. Without it, access to PaymentFlo will be blocked. 2FA settings are available in the user's profile. Only an Administrator or Developer can reset 2FA using the "Disable 2FA" button when viewing the user's details in the admin panel.

4. Shipments

4.1 General Information

Shipments are created automatically if the store has the Shipment option enabled and configured, and the order transitions to the "Paid" status. Each Shipment is associated with a specific order. Each order can have multiple Shipments and resends.

The Shipment is generated both in the external service and in PaymentFlo. The state of these Shipments is synchronized every 2 hours.

Currently, the following services are available as a Warehouse Management System (WMS):

  • Linnworks (see 1.4.7)

4.2 Shipment Statuses

PaymentFlo has 3 Shipment statuses:

  1. Open - Initial status. Shipment is not sent.
  2. Processed - Shipment is sent, tracking data is received.
  3. Canceled - Shipment is canceled.

4.3 Shipment Resend

A resend can only be created based on a processed or canceled Shipment. The resend follows the same path as the Shipment. When creating a resend, there is an option to choose which specific products that need to be resent. New products can be added when editing the resend.

4.4 Stamps Integration

The Stamps integration (see 1.4.4) was added to PaymentFlo to have the capability of calculating specific amounts spent on shipping orders. If this integration is enabled for a store, when creating and updating a Shipment, PaymentFlo sends a request to Stamps, which calculates the shipping cost based on the weight of the products and the packaging used.

4.5 Aftership

Aftership enables tracking the delivery status and sends callbacks to PaymentFlo whenever there is a status update. For each callback received, PaymentFlo sends an event through the mailer with the name of the new status. If the status is "delivered," the order status is changed to "Delivered" in PaymentFlo.

5. Payments

Payments are options for order Payment. When attempting to make a Payment, a transaction is created and linked to the order, which then takes on a status depending on the Payment result. The Payment code is recorded in both the transaction and the order.

5.1 Payment Types

Payment types allow grouping Payments to simplify the selection process for customers. Each Payment must be assigned to a specific Payment type.

When creating a new Payment type, the following fields need to be filled:

  1. Enabled - Status of the Payment type.
  2. Order - Responsible for sorting in the admin panel and for the customer.
  3. Title - Name of the Payment type, visible on frontend.
  4. Code - Code of the Payment type, used for technical purposes.
  5. Multipayment - If enabled, customer able to choose from a few Payments.
  6. Random Payments - If enabled, Payments will be shown in random order. It makes sense to have it enabled only if multipayment is disabled.
  7. Recommended - Marks this Payment type as recommended on the frontend.
  8. Has Notice - Displays a question icon next to the Payment type title. The content is stored in view files.

5.2 Manual Payments

Manual Payments allow customers to create their own Payments that do not involve custom logic, e.g. Pay by Cash, Pay by Check.

5.3 Payment Settings

5.3.1 Custom Settings

Non-manual Payments typically include custom fields that store connection parameters to an external service. These fields are displayed at the top of the page when editing the Payment.

5.3.2 Common Settings

  1. Enabled - Show/hide payment on frontend for customers and on order page in admin.
  2. Visible - Show/hide payment on frontend for customers.
  3. Show Only For Verified Customers - Show payment only for returned customers that already have at least one paid order.
  4. Lock Shipping Address To Billing Address - Replace shipping address with billing address if this payment is selected.
  5. Order - Position of payment in the list of payments.
  6. Currency - Payment currency. If order has another currency and customer chooses this payment, order amount will be converted to the payment currency using Currency Rates (see 8.3).
  7. Title - Title of the payment. Will be displayed for customers.
  8. Title Description - Payment description for additional exploration. Links with Title.
  9. Code - Payment code. It is used in orders and transactions and is also displayed to customers to avoid taking up too much space.
  10. Block Orders By Address - Payment filters by customer address. Type of address field determines what address will be used for filter: Billing, Shipping or both.
  11. Disallow PO Boxes - Filters Payment if customer shipping or billing address contain Box in the address line.
  12. Fraud Level - Determines level of fraud check (see 2.5) in Fraudlabs (see 7.6) for the customer. Can be one of these:
  • OFF - Request won’t be sent to Fraudlabs;
  • LOW - Move order to fraud review if Fraudlabs returned only Reject status;
  • HIGH - Move order to fraud review if Fraudlabs returned Reject or Review status.

13. Payment Description - Payment description displayed in the list of payment on the Payment page.

14. Success Instruction - Payment instruction or success message will be showed to the customer on success page.

15. Payment Instruction - More concrete Payment instructions, used only for API currently.

16. Default Descriptor - Actual only for CC payments. Descriptor that customer sees in his bank account. Can be changed by agents on the order page if there are a few values specified.

17. Short descriptor

18. Payment Charge - Fee that customer pays for using this Payment method. Can be fixed or percent-based. Can be negative

19. Has Luckydip - If enabled, auto-discount is added. A random value for $0 to $1. Is used mostly for offline payments (see 5.6).

20. Remove Gifts After - If enabled, Payment gifts are removed after specific time.

21. Abandoned Points - If specified, Payment instructions for this Payment are sent again on the hour points. If “cancel on last point enabled”, order will be canceled on the last hour point.

22. Gifts - A feature that allows to add free products if customer chooses this Payment method.

23. Max/Min Order Amount - A filter that hides this Payment if order amount is more or less than specified values.

24. Payment Info Rotation - A feature that allows clients to have a few Payment credentials for this Payment method. Works only for manual Payments.

  • Random rotation - If enabled, the credentials will be assigned in random order;
  • How much money before rotate payment info - Sum of order amounts in a day after which next credentials will be used;
  • How many orders before rotate payment info - Orders count in a day after which next credentials will be used;
  • How many rotates per day before payment is hidden;
  • Payment info list - List of Payment credentials.

25. Alert Notifications - A feature that allows clients to receive a notification if there are too many orders with failed status with this Payment.

26. Visibility Time - Filter that hides this Payment if current time is out of the specified.

5.4 Copy Payments

Users with Developer role are able to copy one or several Payments to another store.

5.5 Tokenization

Tokenization is currently only enabled for ACHPC Payment method. It allows customers to save tokenized credentials of their ACH account in PaymentFlo database and use them in the future without being forced to enter them again. Can be expanded to CC Payment methods.

5.6 Offline Payments

Offline Payments assist clients in processing Payments made through manual Payments by handling emails sent by services such as Zelle, Venmo and Cash App. This feature collects the emails from a client’s mailbox and tries to find a related Order. If an Order is found, it is marked as paid. Also there is an ability to add your own records for Payments like cash or check.

6. Global Settings

The Global Settings page is designed for configuring settings that are common to all stores.

6.1 Global Settings Types

6.1.1 General

General Settings

  1. Support Email - The email address specified as the sender when sending email like reset password or transaction alerts.
  2. Password Reset Token Expire - Time in seconds after which the password reset token will expire.

6.1.2 Currency rates source

API settings for currency rates (see 8.3) feature:

  1. API Name - Name displayed to customers.
  2. API URL - URL of the service API e.g.: http://api.exchangeratesapi.io/v1/latest?access_key=.
  3. API Key - Secret key for the service.

6.1.3 TinyMCE

API key for WYSIWYG editor https://www.tiny.cloud/.

6.1.4 Fraudlabs

Settings related to global account for Fraudlabs (see 7.6)(https://www.fraudlabspro.com/), part of Fraud Review feature (see 2.5).

  1. API Key - Secret key for the service.
  2. API URL - URL to API e.g.: https://api.fraudlabspro.com/v1/order/.

6.1.5 Alert Notifications

Settings related to Alert Notifications feature (see 8.4).

  1. Enable - Status of the feature.
  2. Emails - List of emails separated by comma that will receive the notification emails.

6.1.6 Sendgrid

API Key for global sendgrid account for Sendgrid feature (see 1.5.3).

7. Custom Integrations

7.1 Linnworks

One of the shipment services (see 4). For this service PaymentFlo has a custom application that should be used to connect stores to Linnworks. It can be found here (https://developer.linnworks.com/).

7.2 Shipstation

One of the shipment services (see 4).

7.3 Drip

One of the email services (see 1.5.2). Supports events.

7.4 Klaviyo

One of the email services (see 1.5.2). Supports events.

7.5 Sendgrid

One of the email services (see 1.5.3). Does not support events.

7.6 Fraudlabs

Service for Fraud Review feature (see 2.5).

7.7 Zendesk

This integration creates and synchronizes orders in Zendesk.

7.8 Swell

If this integration is enabled, PaymentFlo displays the count of points available for the customer on the order view page. It’s displayed in the Customer Info section. It also includes the ability to increase or decrease the amount of points.

7.9 PostAffiliatePro

Affiliate management system. If enabled, PaymentFlo sends paid and canceled events for orders to this system.

7.10 Affiliatly

Affiliate management system. If enabled, PaymentFlo sends paid and canceled events for orders to this system.

7.11 Jotform

A forms management system. PaymentFlo receives webhooks from this system and changes substatus for the orders.

8. Additional Features

8.1 Stock Sync

If enabled, stores will be updated with stock levels downloaded from LW or other shipping service. Every 3 hours + when LW sends a webhook with updated inventory.

8.2 Banned Customers

This feature allows clients to ban undesirable customers. When banned customers try to pay, their order goes straight to Fraud Review (see 2.5)

There are a few ways for clients to ban a customer :

  1. Add a ban manually using Banned Customers page;
  2. Ban customer from order view page;
  3. When order status is changed to Chargeback.

To create a ban these fields should be filled:

  1. Type Of Ban -
  • Global - Customer will be banned in all stores
  • Global Payment - The specified payment will never be shown in any store for this customer
  • Payment - The specified payment will never be shown in current store for this customer

2. Timeout - Create a temporary ban. The customer will be unbanned in specified hours

3. Internal Notes - Any info about the ban. Won’t be shown to the customer

8.3 Currency Rates

This feature allows Paymonix to convert order amounts if the order currency and payment currency are different.

On the Currency Rates page users with Admin role are able to add a rate, sync rates, enter them manually or enable auto-update for added rates that will happen every day.

8.4 Alert Notifications

This function is designed to notify developers about a drop in the number of orders by more than 50% in the last hour compared to the average value over the previous 3 weeks (see 6.1.5). For sending notification email Amazon SES is used.

9. Email Service Events

9.1 Default Events

  1. Placed an order;
  2. Paid an order;
  3. Canceled an order;
  4. Refunded an order.

9.2 Custom Events

  1. payment_instructions_{payment_code}
  2. payment_failed - Used for Failed Orders, see 2.4.
  3. payment_failed_repeat - Used for Abandoned Failed Orders, see 1.5.7.
  4. abandoned_cart - Used for Abandoned cart emails, see 1.5.6.
  5. shipment_processed - Used if tracking number is missed.
  6. tracking_update_{tracking_status} - Fires when Aftership (see 1.5.9) webhook is received. Available statuses:
  • inforeceived
  • intransit
  • outfordelivery
  • attemptfail
  • delivered
  • exception
  • expired

7. new_affiliate - Used for PAP feature, see 1.5.12.

8. send_card_receipt - Used when admin or sales manager clicks on Send Card Receipt button on the order view page.

9. send_achpc_receipt - Used when admin or sales manager clicks on Send ACH Receipt button on the Order View page.

10. order_fraud - Used when order is moved to Fraud Review, see 2.5.

11. payment_return_check - Return check for eChecks.

12. ws_order_created - Used when an order is created for Wholesale stores, usually by Zendesk integration, see 1.5.8.

13. ach_verification_fail - Event for ACHPC payment method.

14. ach_verification_fail_last - Event for ACHPC payment method.

15. jotform_reminder - Used for Jotform integration, see 7.11.