Orders

  • What are your order requirements?
    1. What is your standard order fulfillment workflow? How are orders received, processed, shipped?
    2. If using Counterpoint for your destination application, do you have any ticket or sale-related customizations?
    3. If using Counterpoint, what store, station, drawer and user ID should ecommerce orders be assigned to?
    4. Would you like to or do you plan to make any changes to your order fulfillment process during this project and before launching your site?
    5. Do you have any special purchase requirements for your customers?
    6. Do you accept “special instructions,” “gift messaging” or other order information that need to be imported with the order?
      • Is this information obtainable using the standard API and has the source destination for this information been defined or already exists?
      • Are measures in place to prevent or remove invalid characters or out-of-range values?
      • Does this additional information need to be imported from:
        • The order “header”
        • The order “line items”
        • A bill-to or ship-to address
        • One or more order payments or payment “events”
        • Comments/Notes
        • A 3rd party add-on
      • Is the information ready to use as-is or does it need to be converted/additional information added in the destination system?
  • Do you have any custom order data that should be migrated from a different location to your source application for this project? 
  • What payment methods will you offer? EX: Authorize.net, ApplePay, PayPal, AfterPay etc
    1. How do you intend to capture and reconcile payments for each payment processor?
    2. Do you intend to prevent transferring orders to iPaaS that do not meet a particular payment status?
    3. Do you currently have a process to verify the payments are captured and settled successfully?
    4. Do you currently have a process to refund or cancel payments in either or both source and destination systems?
    5. Do you intend to automate any of the payment capture/cancel/or refund functionality between integrated systems?
      • If so, is that automation currently a feature of iPaaS or is new development necessary?
    6. Should a capture/cancel/refund event occur, what information or actions are you looking to integrate to iPaaS and other systems afterwards?
      • Are those actions a current feature of iPaaS or is additional development necessary?
    7. Has a plan been developed to handle incorrect or conflicting payment information from a source system?  For example, an order may claim the total is $100.00 but the payment information from the same system may claim that $99.99 was received appearing in other systems as if $0.01 is still due.
      • If so, does this plan designate who will be responsible for identifying, correcting, or working around the incorrect or conflicting payment information?
    8. Has a corresponding payment method been created in the destination system to represent the source payment method?
      • If so, does it meet all requirements to use it? (For example, is the pay code in Counterpoint allowed for orders and at the store you want to import orders into)
    9. Are you aware of anything that might alter the payment information in the source or destination system after the data was originally created? (For example, a Counterpoint customization to update the pay code based on some criteria)
      • Has a plan been implemented to identify and resolve errors with the customization or requirements not being met?
    10. If using Counterpoint, are order deposits fully configured and do your expectations align with iPaaS.com deposit ticket logic?
      • (Captured payment at time of initial import = deposit ticket)
      • (Payment not captured at time of initial import = no deposit ticket)
      • (Gift card payment on order = deposit ticket for gift card portion)
    11. Do you intend to transfer additional payment information from one system so that another system can manage the payment?  For example, an Authorize.net token is obtained on the website, but payment actually captured from another system using the same token.
      • Is this information already available for download from the source system, or if present able to use in the destination system?
      • Should the source system be updated after this event occurs or do other mechanisms exist to prevent double-charging?
    12. Should any of the intended behavior discussed above work differently when a different payment type/provider is used?
  • What tax requirements do you have? EX: In-State, Out of State, specific tax authorities
    1. How often are they subject to change?
      • Has a plan been developed to inform Red Rook ahead of any tax changes and/or deployment to staging for verification before applying to production?
    2. Have you defined who is responsible for configuring and troubleshooting the website tax configuration?
    3. Are the tax configurations between source and destination systems identical?
      • For example, matching state, county, and city tax definitions exist in both systems
      • Similar product tax category configurations (Food, clothing, service)
      • For example, the website provides a single tax definition but the destination system requires the tax to be broken out among different tax authorities
      • If different, has a plan been developed to make them identical?
    4. Does the tax information provided by the order change after the order has been placed? (BigCommerce Avalara add-on will do this for example)
      • If so, would you like to prevent an order from transferring to iPaaS and destination systems until this change occurs?
  • What shipping methods will you offer? EX: UPS, USPS FedEx etc
    1. Has a corresponding shipping method been created in the destination system to represent the source shipping method?
    2. If so, does it meet all requirements to use it? (For example, is the shipping method in Counterpoint allowed for customers?)
    3. Will you allow multiple ship-to addresses on an order?

Customers

  • Do you require customers to be migrated from a specific application to your source or destination application? 
  • Do you require customer order history to be migrated from a specific application to your source or destination application?
  • Do you segment your customers? EX: customer groups
    1. Do you have special pricing for any different groups of customers? Do you have any special rules that apply to certain customers or groups of customers?
  • How do you create a customer? What are the requirements for creating an ecommerce customer?
    1. What purpose do you have for your ecommerce customers?
  • Do you ever need to remove ecommerce customers from the site? 
    1. If so, how is this handled? 
  • Do you have any custom customer data that should be migrated from your primary applications for this project? 
  • What fields should be integrated for customers? Examples include customer name, billing and shipping addresses, phone number, email, customer category, DOB etc.
  • Have you defined what customer data points are required to create a customer in both the source and destination applications?
    1. Have these requirements been met or is there a plan in place to meet these requirements?