Web Store
2Checkout
Connect your AI to 2Checkout
Finance and billing managers, e-commerce and sales operations managers, and customer support teams run online sales through 2Checkout, but orders, subscriptions, customers and payouts sit on separate screens that are slow to cross-check. AI can pull those answers together in seconds, but only if it reads just what the connected merchant account is permitted to see and keeps customer and payment details with the person asking.
Why it matters
Capabilities that matter most for 2Checkout
01
Ready-made read tools for 2Checkout
41 Get data tools in the app store cover orders, customers, subscriptions, products, promotions, payouts, leads and partners, so an AI client can answer sales questions without custom setup.
02
Worked jobs, not just tools
18 read-only prompts in the app store turn those tools into finished jobs, such as reviewing the health of one subscription or finding everything a customer owns.
03
2Checkout beside your other systems
Cross-system prompts pair 2Checkout with 14 connectors, including Stripe, Salesforce, HubSpot, NetSuite and Business Central, so one question can span billing and the CRM or ledger.
03
Governed by your merchant account
Tools return only what the connected 2Checkout account can see, and the read-only prompts never call a write tool, so personal and payment data stays with the person asking.
Use cases
Example AI Use Cases for 2Checkout
scenario
-
A customer writes in and support has to open 2Checkout for their subscriptions, then Drip for their subscriber status, tags and campaigns, and line the two up by hand. A paying customer who is unsubscribed in Drip, or who appears under a different name, is easy to miss.
What popdock provides
--
Give a customer email and it finds the customer and subscriptions in 2Checkout, then the same person in Drip, and builds one profile with credit remaining, subscription status and expiry, Drip status, lead score, lifetime value, tags and campaigns. People are matched on email only, never on name. It stops if several 2Checkout customers match, shows both names when the systems disagree, and nothing is changed in either system.
Business outcome
---
Support sees billing and email marketing status for one customer side by side, with mismatches flagged and no records changed.
scenario
-
To answer a question about one customer, billing and account teams open 2Checkout for subscriptions and orders and Dynamics 365 Sales for opportunities, invoices and cases, then stitch the history together by hand. Orders can only be found by name, so the wrong person is easy to pull in.
What popdock provides
--
Give a customer email and it reads the customer, subscriptions and orders in 2Checkout, then finds the contact and its account in Dynamics 365 Sales and reads opportunities, invoices and cases over the lookback period. Orders matched on last name alone are labelled as probable. If one system has no record it says so and still reports the other, and it ends with three observations such as an unpaid invoice beside an active subscription. Nothing is written to either system.
Business outcome
---
Support and account teams get one cross-system customer history with unsure matches labelled and no data changed.
scenario
-
Answering one customer question means switching between the billing console and the CRM. An open HubSpot ticket, an expired 2Checkout subscription or a contact whose lifecycle stage no longer matches their billing is easy to overlook when you only look in one place.
What popdock provides
--
Give a customer email and it reads the customer and subscriptions in 2Checkout, then finds the contact in HubSpot with lifecycle stage, lead status, owner and last activity, plus their tickets and the company's deals. If several HubSpot contacts share the email it lists them and stops, and if the systems disagree on name or company it shows both values. It closes with a line flagging conflicts, and it only reads data in both systems.
Business outcome
---
Support answers customer questions from one view of billing, tickets and deals, with conflicts flagged and nothing edited.
scenario
-
Support staff open 2Checkout to see what a customer pays for and Mailchimp to see whether they still receive email. Checking both by hand takes time, and a paying customer who is unsubscribed or listed under a different name goes unnoticed.
What popdock provides
--
Give a customer email and it finds the customer and subscriptions in 2Checkout, then the same email in Mailchimp, listing each audience with status, tags, VIP flag and average open rate, plus opens, clicks and bounces over the lookback period. It stops if several 2Checkout customers match, shows both names if they differ, and flags an active subscription whose Mailchimp status is not subscribed. Nothing is written to either system.
Business outcome
---
Support sees billing and email marketing status together, with unsubscribed paying customers flagged and no records altered.
scenario
-
Account managers and support jump between 2Checkout and Capsule CRM to learn who a customer is, what they pay for and what is being discussed. Orders can only be matched by name, and one side is easy to miss or the wrong person matched.
What popdock provides
--
Give a customer email and it reads the customer, subscriptions and recent orders in 2Checkout, then finds the contact in Capsule CRM with owner, last contacted date, open opportunities and tasks. It stops if several 2Checkout customers match, says the order match is by name and may include someone else, treats a company name match as probable only, and never adds amounts across currencies. A gaps section shows what exists in only one system. Nothing is changed.
Business outcome
---
Account and support teams see billing and relationship context together, with gaps and uncertain matches called out and nothing edited.
scenario
-
Before a renewal call, a rep checks Salesforce for the account and its contacts, then looks each contact up in 2Checkout for subscriptions. A subscription close to expiring with no open opportunity behind it is easy to miss, and contacts with no billing record go unnoticed.
What popdock provides
--
Give a Salesforce account name and it finds the account, matches its contacts to 2Checkout customers by email, and lists their subscriptions with status and expiry, highlighting those expiring within your window. It adds the account's open opportunities and ends with risks and openings, such as an expiring subscription with no open opportunity. It stops if the account name is ambiguous, reports contacts with no billing record, and changes nothing in either system.
Business outcome
---
Reps walk into renewal calls knowing which subscriptions are about to expire and which have no opportunity behind them.
scenario
-
An agent working a Salesforce case has to open 2Checkout separately to find the customer's subscriptions and payment history. With similar customer names it is easy to read the wrong customer, and a failed payment that explains the case can be missed.
What popdock provides
--
Give a Salesforce case number and it reads the case, finds the customer in 2Checkout by the contact email, and lists their subscriptions with status, expiry and latest payments, plus orders if you ask for them. It stops if the case or customer is not found, picks among several customers only on a name match and otherwise asks you, and says plainly when the billing data does not explain the case. Nothing is written to either system.
Business outcome
---
Agents see a case and its billing context together, so they can answer without opening a second system or guessing at causes.
scenario
-
Affiliate commissions are checked by hand against order exports. A wrong rate on one affiliate, or an inactive affiliate who still earns commission, can go unnoticed for months because nobody recalculates each order.
What popdock provides
--
Give an affiliate code and it reads the affiliate's name, status, commission rate and terms status from 2Checkout, then scans their orders and compares the commission on each with the discounted gross price times the configured rate. It reports order count, total gross, total commission and effective rate, lists orders more than one percentage point off, and notes an inactive affiliate still earning. It states how many orders were scanned and only reads data.
Business outcome
---
Finance spots commission errors and inactive affiliates still earning, from a stated sample, without changing any affiliate or order.
scenario
-
Price option groups pile up unused entries and inconsistent impacts, and nobody is sure which products depend on a group. Editing one without knowing its reach can change prices on many products at once.
What popdock provides
--
Optionally name part of a group, and it reads the matching price option groups in 2Checkout with their options, usage, price impact and scale ranges, then finds which pricing configurations and products attach each group. It reports unused groups, groups with no options or no default on a required group, scale ranges that overlap or leave gaps, and groups used by more than five products. Nothing is edited, and it stops if there are no groups.
Business outcome
---
Operations see which option groups are unused, broken or risky to edit, before anyone changes a price.
scenario
-
Catalog gaps such as a product with no default pricing configuration, a missing currency price or no image are usually found only when a customer runs into them. Checking each product by hand across several screens is slow.
What popdock provides
--
Give a product code, or leave it blank for the whole catalog, and it reads the product, its pricing configurations, prices in each currency, attached option groups and images in 2Checkout. It confirms exactly one default configuration, flags zero prices, a missing default currency price and missing or default images, and gives each product a verdict with a bullet per defect. It only reads data and stops if the product code matches nothing.
Business outcome
---
Operations find catalog gaps before customers do, with one verdict per product and no product or price changed.
scenario
-
Old promotions stay enabled, coupons overlap and nobody can say which discounts are live and what they cover. A promotion past its end date, or a large discount that also applies to renewals, can cost margin unnoticed.
What popdock provides
--
Optionally set a minimum discount and a promotion type, and it reads the matching promotions in 2Checkout with dates, discount, cumulative and recurring settings, then checks the products and coupons attached to each enabled one. Findings are ranked by risk: enabled past end date, no products attached, cumulative promotions that could stack, large discounts on recurring charges and reused coupon codes. It ends with counts of live, expired and disabled, and edits or deletes nothing.
Business outcome
---
Marketing sees which promotions are live, expired or risky, ranked by risk, without touching a promotion or coupon.
scenario
-
Usage billed subscriptions are invoiced from usage records that nobody reconciles. Missing intervals, overlapping records, duplicate references or a spike in units can bill a customer wrongly, and they are hard to see in a raw list.
What popdock provides
--
Give a subscription reference, and optionally one option code, and it reads the usage records from 2Checkout, sorts them by start time and checks for overlaps, gaps between intervals, duplicate usage references and unit counts more than three times the median. You get units per option code and a list of defects. It only reads data, does not add, edit or delete usage or trigger billing, and does not suggest fixes you did not ask for.
Business outcome
---
Finance finds usage billing defects before invoices go out, with no usage record changed and no billing triggered.
scenario
-
Operations staff check by hand whether each product sold on a 2Checkout order exists as an item in Dynamics GP with a price. Gaps usually only show up when invoicing fails, and comparing prices across screens and currencies invites mistakes.
What popdock provides
--
Give a 2Checkout order reference, and optionally a Dynamics GP company, and it reads the order lines and product names, then looks each product up as a Dynamics GP item by SKU or product code, falling back to the description. It compares the GP list price with the 2Checkout unit price per line and lists products not in Dynamics GP. If several items match it lists them without choosing, it will not compare prices across currencies, and it writes nothing to either system.
Business outcome
---
Operations learn which sold products are missing or priced differently in Dynamics GP before invoicing fails, with no items created.
scenario
-
Refunds issued in 2Checkout are not always booked as credits in NetSuite, so the books drift. Finance has to find each refunded order and then look for a credit memo or customer refund that lines up, and a missing credit is easy to overlook.
What popdock provides
--
Give a customer email and a start date, and it finds the customer and refunded or cancelled orders in 2Checkout, then reads that customer's NetSuite credit memos and customer refunds. Each refunded order is matched to a credit by date within 14 days, or marked as having no credit found, and NetSuite credits that match no refund are listed. It says plainly that amounts were not compared, stops on a missing customer and only reads data.
Business outcome
---
Finance finds refunds with no matching NetSuite credit, and credits with no refund, before the books drift further.
scenario
-
Nobody can easily tell whether a customer with an expiring 2Checkout subscription has been contacted. Without checking the CRM person by person, renewals lapse unattended while effort goes to accounts that were already called.
What popdock provides
--
Set how many days ahead to look for expiring 2Checkout subscriptions and how far back to check, and it takes up to 30 active subscriptions, finds each subscriber in Pipedrive by email, and counts their recent activities and notes with the latest contact date. Subscribers with no outreach are listed first, then those not in Pipedrive, and a person with no activity is treated as no outreach rather than missing. It only reads data in both systems.
Business outcome
---
Customer teams see which expiring subscriptions have had no outreach, so no renewal lapses unattended, with no records changed.
scenario
-
Collections staff look up a subscription in 2Checkout, then search Rillet for the buyer's open invoices, and often chase the wrong person or miss that the renewal currency differs from the invoices. Matching the two by hand is slow.
What popdock provides
--
Give a buyer email, or a subscription reference, and it finds the subscription in 2Checkout with status, expiry and renewal price, then finds the buyer in Rillet by email and reads their invoices with amounts due and overdue flags. It stops if several subscriptions match and reports a missing Rillet customer instead of guessing. It totals the amount due, flags an active subscription with overdue invoices or a currency difference, and writes nothing to either system.
Business outcome
---
Collections know what renews and what is still owed in one view, with the right buyer matched and nothing changed.
scenario
-
Sales and finance compare closed deals in Capsule CRM with subscriptions in 2Checkout by eye. Won deals never get billed, lost deals keep charging, and matching a deal to the right customer means finding each contact email first.
What popdock provides
--
Name a deal stage and how many deals to review, and it lists the Capsule CRM opportunities at that stage, finds each contact's email, and checks 2Checkout for a matching subscription, telling a customer with no subscription from one unknown to 2Checkout. It skips ambiguous contacts, never matches by name in 2Checkout, and does not compare prices. It lists the deals needing follow-up, such as a Won deal with no active subscription, and changes nothing.
Business outcome
---
Sales and finance find won deals that were never billed and lost deals still charging, without changing any record.
scenario
-
Renewal teams cannot tell which expiring 2Checkout subscribers are engaged, so effort goes to the wrong accounts. Checking auto-renew in one system and lead score and tags in another for every subscription is too slow to do by hand.
What popdock provides
--
Give a start and end date, and it lists the 2Checkout subscriptions expiring in that window with their auto-renew setting, then looks up each owner in Drip for status, lead score and tags. Owners missing from Drip are flagged, the table is sorted by expiry, and rows with auto-renew off and a high lead score are marked as the best manual outreach targets. It only reads data and sends no emails.
Business outcome
---
Renewal teams aim manual outreach at engaged subscribers whose auto-renew is off, with no emails sent and nothing changed.
scenario
-
Marketers export expiring 2Checkout subscriptions and hand-match the emails against Mailchimp. Renewal emails then go to people who unsubscribed or never made it into an audience, and nobody notices until the renewal lapses.
What popdock provides
--
Set how many days ahead to look, and optionally a product name, and it lists active 2Checkout subscriptions expiring in that window, up to 50, then checks each distinct email in Mailchimp. Subscribers are grouped as reachable, blocked (unsubscribed or cleaned) or missing, soonest expiry first, with a count per group. Blank emails are listed as missing with a note, several audiences are shown separately, and it only reads data.
Business outcome
---
Marketing knows who can still get renewal emails and who cannot, before a campaign goes out, with no records changed.
scenario
-
Collections staff chase unpaid Stripe invoices without knowing whether the same customer is still active in 2Checkout. The two systems share no subscription id, so the only link is the email, and chasing someone who has already left wastes effort.
What popdock provides
--
Give a customer email and it finds their open Stripe invoices, falling back to uncollectible ones, with number, amount remaining, due date and link, then reads their 2Checkout subscriptions with status and expiry. It joins the two only on email, stops if nothing is unpaid, reports the customer as absent from 2Checkout when no subscription is found, and says plainly whether they are unpaid in Stripe while still active in 2Checkout. It only reads data.
Business outcome
---
Collections see whether an unpaid customer is still active in 2Checkout before they chase, with nothing changed in either system.
scenario
-
Renewal reminders are planned from the 2Checkout list of subscriptions about to expire. Nobody checks whether those owners are still allowed to receive email in Constant Contact, or whether they ever open anything, so reminders go to people who unsubscribed or to addresses that were never added.
What popdock provides
--
Say how many days ahead to look, and it finds the active 2Checkout subscriptions due to expire in that window. It looks up each owner's email in Constant Contact, reads their permission to send, and checks the latest activity for those who can be emailed. You get owners grouped as reachable and engaged, reachable but silent, unsubscribed, or not in Constant Contact, soonest expiry first. Nothing is changed and no campaign is sent or resent. Subscriptions with no email are listed as unmatchable.
Business outcome
---
You know which expiring subscribers can actually be sent a renewal email, and how engaged they are, before a reminder campaign is planned.
scenario
-
Money paid out by Stripe and by 2Checkout lands in the bank on different schedules and in different currencies. Totalling both for a period means exporting two reports into a spreadsheet, filtering by date and currency, and hoping nothing is mixed up along the way.
What popdock provides
--
Give a start date, an end date and optionally a currency, and it reads the Stripe payouts that arrived and the 2Checkout payouts that were transferred in that period. For each currency it reports the Stripe total, the 2Checkout total, the combined total and how many payouts sit in each status on each side, then lists any payout that is not yet paid or completed. It checks the date range first and stops if the dates are reversed. Nothing is changed, and fees are not netted off.
Business outcome
---
Payouts from both processors are totalled per currency in one answer, with unfinished payouts called out, and no spreadsheet merge.
scenario
-
Leads captured through 2Checkout and the subscribers in Drip drift apart because nobody compares them. Matching by hand means checking each lead email in Drip one at a time, so some leads never get nurtured and nobody notices the gap.
What popdock provides
--
Optionally name a billing country, and it reads the 2Checkout leads and checks each lead's email in Drip. You get the leads that are not in Drip, the leads that are with their Drip status and lead score, and a count of leads with no email. People are matched on email only, ignoring case and spaces, never on name. If Drip holds a different name for the same email, both are shown. Nothing is changed in either system.
Business outcome
---
Gaps between your 2Checkout leads and Drip are listed in one pass, matched on email only, so no lead is left outside nurture.
scenario
-
A customer exists in both 2Checkout and Dynamics GP, and the two records slowly disagree. Someone compares names, addresses, credit limits and active flags by eye across two screens, and the difference only surfaces when an invoice or a credit check goes wrong.
What popdock provides
--
Give a customer email and optionally a Dynamics GP company, and it finds the customer in 2Checkout and then the matching customer in Dynamics GP. It reports each attribute with both values and marks it as a match or a difference: name, email, address, city, country or state, credit limit and active state, allowing for GP storing that flag the other way round. It stops and lists candidates if several customers match, and it says so if the customer is missing from GP. Nothing is changed in either system.
Business outcome
---
Finance sees every field where a 2Checkout customer and its Dynamics GP record disagree, with both values side by side, in one answer.
scenario
-
When a customer is in both 2Checkout and NetSuite, someone compares the two records by hand to see whether the name, phone and currency still agree. Small mismatches are easy to miss, and matching on name alone can link the wrong customers.
What popdock provides
--
Give a customer email and it looks the customer up in 2Checkout and in NetSuite, using email as the only join. It compares email, name, phone and currency where both sides hold them, ignoring case and spacing, and reports each field with both values as a match or mismatch. It adds the 2Checkout customer reference and the NetSuite internal ID so the records can be linked. It stops if either system returns several customers, reports the customer as absent if one side has none, and changes nothing.
Business outcome
---
Finance gets a field by field comparison of one customer across 2Checkout and NetSuite, with the record references to link them.
scenario
-
A customer's details are held in both 2Checkout and Stripe, and billing staff compare them by eye when something looks off. A different city, a missing phone number or a disabled flag on one side is easy to overlook across two dashboards.
What popdock provides
--
Give a customer email and it finds that customer in 2Checkout and in Stripe. It compares name, company, city, country, phone and the enabled or delinquent state, ignoring case and surrounding spaces, and treats a value missing on one side as a difference. You get a table of both values per field with the 2Checkout customer reference and the Stripe customer ID on top. It stops and lists candidates if more than one customer matches, and nothing is changed in either system.
Business outcome
---
Billing staff see where one customer's 2Checkout and Stripe records disagree in a single table, without opening either dashboard.
scenario
-
A customer can hold subscriptions in both 2Checkout and Stripe, and the two systems drift. One shows active while the other shows cancelled, or the end dates are days apart. Checking means opening both billing tools and pairing subscriptions by eye.
What popdock provides
--
Give a customer email and optionally a status, and it lists that customer's subscriptions in 2Checkout and in Stripe. It pairs them by product, flags pairs where one side is active and the other cancelled or expired, and flags end dates that differ by more than three days. Status names are mapped by meaning and it tells you how. Subscriptions whose product cannot be matched stay unpaired rather than forced into a pair. Nothing is changed in either system.
Business outcome
---
Status and expiry mismatches between a customer's 2Checkout and Stripe subscriptions are flagged in one table, with unpaired ones listed separately.
scenario
-
When a customer contacts support, finding everything they own in 2Checkout means searching customers, subscriptions and end users separately. A name variant or a buyer who exists only as an end user makes the search come back empty, and the customer is told they have nothing.
What popdock provides
--
Give an email address or a last name, and it finds the customer in 2Checkout. If the buyer is not a customer it also tries the subscription end users. It then lists their subscriptions with reference, product, status, activation and expiry dates and whether each is enabled, ordered by expiry. It points out anything unusual, such as expired or disabled subscriptions, repeats on the same product or mismatched emails. If several customers fit it lists them and stops so you can choose. Nothing is changed.
Business outcome
---
Support can see all of a customer's 2Checkout subscriptions with status and expiry in one answer, even when the buyer is only an end user.
scenario
-
Account managers export the subscriptions about to expire from billing, then look up each customer's owner and open deals in the CRM by hand. Customers with no CRM contact slip through, so their renewals end up with nobody following up.
What popdock provides
--
Give a start and end date and optionally a row limit, and it reads the 2Checkout subscriptions expiring in that window. For each subscriber email it finds the HubSpot contact, owner and lifecycle stage, and the open deals on their company. You get a table sorted by expiry, with subscriptions that have no HubSpot owner listed separately instead of guessed. It asks for valid dates first, lists the contacts if several share an email, and changes nothing in either system.
Business outcome
---
Renewals can be assigned because every expiring subscription is shown with its HubSpot owner and open deals, and unowned ones are flagged.
scenario
-
Subscriptions due to expire are exported from 2Checkout and matched to Pipedrive by hand, one subscriber at a time. People who are not in Pipedrive, or who have no email, get missed, and renewals end up with no rep behind them.
What popdock provides
--
Say how many days ahead to look and optionally a product, and it reads up to 50 active 2Checkout subscriptions expiring in that window. For each subscriber with an email it looks up the person in Pipedrive and records the owner, organization and open deals. You get a table sorted by expiry, counts per owner, and a list of subscribers with no Pipedrive person or no email. Blank emails are reported rather than guessed, and nothing is changed in either system.
Business outcome
---
The right rep can follow up on every expiring subscription, with unmatched subscribers and blank emails listed instead of lost.
scenario
-
Leads captured in 2Checkout are meant to land in a Mailchimp audience for nurture emails, but nobody compares the two. Checking by eye, lead by lead, means some leads never receive a single email and the gap goes unnoticed.
What popdock provides
--
Name a Mailchimp audience and optionally how many leads to check, and it reads the 2Checkout leads and looks up each billing email in that audience. You get the leads with no member row, a short list of leads present but not subscribed with their status, and counts of leads checked, present, missing and skipped for no email. It stops if the audience is not found or no leads come back. Emails are matched ignoring case and spaces, and nothing is added or changed.
Business outcome
---
Sales sees which 2Checkout leads never reached the Mailchimp audience, so they can be added before the nurture sequence runs.
scenario
-
Leads captured in 2Checkout are meant to reach a sales rep through Pipedrive, but nobody compares the two systems. Checked by eye, some leads never appear in Pipedrive, and nobody follows up on people who have already shown interest.
What popdock provides
--
Optionally name a billing country and how many leads to check, and it reads the 2Checkout leads that have a billing email. It looks each email up in Pipedrive and notes the owner and open deals for the ones it finds. You get a table of leads with no Pipedrive person, the known leads with their owner, and counts of checked, known, missing and skipped for no email. It never creates the missing people, and nothing is changed in either system.
Business outcome
---
Sales can pick up every 2Checkout lead that never reached Pipedrive, with the missing ones listed and nothing created without a human decision.
scenario
-
Marketing exports 2Checkout leads and compares them with Salesforce by eye. Some leads never reach the CRM, and others have already been entered as a lead or a contact, so people chase duplicates while real gaps stay hidden.
What popdock provides
--
Optionally name a billing country, and it reads the 2Checkout leads, working through the first 50 and saying if the list was cut. It checks each email against Salesforce leads and then Salesforce contacts, and counts a lead as covered if either matches. You get counts of leads checked, covered and missing, and a table of the missing leads with name, email, company, city and country. Leads with no email are listed separately as unmatchable. It reports only and creates nothing.
Business outcome
---
Marketing sees exactly which 2Checkout leads are absent from Salesforce as a lead or contact, without creating duplicates.
scenario
-
Orders paid in 2Checkout are supposed to be invoiced in NetSuite, but nobody notices a missed one until month-end. Lining up orders with invoices by total and date is slow, and a currency difference can make a matching pair look unbilled.
What popdock provides
--
Give a customer last name and a start date, and it reads that customer's approved 2Checkout orders since then, leaving out test orders and counting them. It finds the customer in NetSuite and reads their invoices from the same date. Each order is matched to an invoice by total within a cent and a date within seven days. You get matched orders, unmatched orders with reference, date, amount and currency, invoices with no order, and the unbilled value. Currency-only differences are flagged for review, and nothing is changed.
Business outcome
---
Finance finds paid 2Checkout orders that were never invoiced in NetSuite, with the unbilled value, before month-end close.
scenario
-
Finance checks each order from the billing platform against the accounting system by hand. A sale that was never invoiced in Rillet is not recognised as revenue, and the join between the two is only an order reference typed into an invoice number or memo.
What popdock provides
--
Optionally give a billing last name and how many orders to check, and it reads the 2Checkout orders, excluding and counting test orders. It reads the Rillet invoices and matches an order when its reference appears in an invoice number, purchase order number or memo, and says how many matches came from each field. You get orders with no Rillet invoice, matched orders with an amount or currency mismatch, and a count of those in agreement. If a reference appears on several invoices it lists them and does not pick one. Nothing is changed.
Business outcome
---
Finance sees which 2Checkout orders have no Rillet invoice, or an invoice that disagrees, before revenue goes unrecognised.
scenario
-
Month-end close needs every 2Checkout sale booked in Dynamics GP, but nobody can easily see which orders were never entered. Checking order by order against receivables means searching GP repeatedly and trusting that a failed search means nothing was posted.
What popdock provides
--
Say how many orders to check, and optionally a billing last name and a minimum amount, and it reads recent 2Checkout orders, dropping test and unapproved ones and saying how many. It looks each remaining order up in Dynamics GP by customer PO number, first in sales transactions and then in receivables transactions, and records Found or Missing. You get the missing orders largest first with the Found and Missing counts. An order whose lookup errors is listed as Unchecked, not Missing. It reports gaps only and creates nothing.
Business outcome
---
Finance gets a list of 2Checkout orders not posted in Dynamics GP, largest first, in time for close, without creating anything in GP.
scenario
-
Teams export subscribers from billing and then search the CRM one email at a time to see who is not tracked. With dozens of subscribers it is tedious, and the people with no CRM contact are the ones nobody ever calls.
What popdock provides
--
Optionally give a subscription status and a number of days, and it reads the 2Checkout subscriptions expiring within that time. It takes each distinct end user email, up to 50 and saying so if there are more, and checks Dynamics 365 Sales for a matching contact and its parent customer. You get subscribers with no contact, with subscription, product and expiry, subscribers found with their parent customer, and counts. Rows with no email are listed separately. It reads only and creates no accounts or contacts.
Business outcome
---
Sales sees which 2Checkout subscribers have no Dynamics 365 Sales contact, so untracked customers can be added deliberately.
scenario
-
Marketing mails the customer base without knowing which paying subscribers have opted out, because billing data sits in 2Checkout and email permissions sit in Constant Contact. Mailing an unsubscribed customer is a compliance risk, and working it out by hand is slow.
What popdock provides
--
Give a subscription status and optionally a product, and it reads up to 100 matching 2Checkout subscriptions. It checks each owner's email in Constant Contact for permission to send and, for anyone who cannot be emailed, reads the unsubscribe reason and date where recorded. You get owners grouped as can be emailed, unsubscribed with reason and date, and not in Constant Contact, with subscription, product, expiry and counts. It never suggests re-adding an unsubscribed contact, lists subscriptions with no email as unmatchable, and changes nothing.
Business outcome
---
Marketing knows which paying subscribers have opted out or are missing from Constant Contact before the next mailing goes out.
scenario
-
Leaders see customer counts in HubSpot that do not match billing, because lifecycle stages are updated by hand and fall behind. People paying for an active 2Checkout subscription can still sit at lead or subscriber stage, or have no contact at all.
What popdock provides
--
Say how many subscriptions to audit and optionally a status, and it reads that many 2Checkout subscriptions, keeping active ones when no status is given. It looks up each subscriber email in HubSpot and reads the lifecycle stage, lead status and owner. You get the count correctly staged as customer, subscribers at any other stage with email, stage, owner and product, subscribers missing from HubSpot, and the share correctly staged. If several contacts share an email it lists them. It states that only a sample was checked and never changes a stage.
Business outcome
---
Leaders see how far HubSpot lifecycle stages lag behind paying subscribers, with who is mis-staged or missing, without any stage being altered.
scenario
-
Sales wants to follow up with people who opened or clicked a campaign, but cannot tell which of them are already customers or leads without checking each address in the billing system. Warm prospects stay buried in the engagement list.
What popdock provides
--
Give a Constant Contact campaign ID and optionally how many engagements to read, and it reads the opens and clicks and combines them by email address. It looks each person up in 2Checkout as a customer, then as a lead, and classifies them as customer, lead or neither. You get the warm prospects first, then leads, then existing customers, with email, name, whether they opened or clicked and the link where known, plus counts. It states that only the engagements read are covered, and it creates no leads or customers.
Business outcome
---
Sales can contact the engaged people who are not yet customers or leads first, without checking each address in 2Checkout by hand.
scenario
-
Customers whose 2Checkout subscription has expired often keep getting onboarding or upsell email, because the billing system and the email system are never compared. Finding them means exporting lapsed subscriptions and then checking each email address in Drip by hand.
What popdock provides
--
Give a subscription status (expired by default) and it reads the matching subscriptions from 2Checkout, then checks each owner's email address in Drip to see who is still active in a campaign. You get each person, the product that lapsed, the expiry date and the campaigns they remain in. People are matched on email address only, never on name alone. Nothing is changed in either system and nobody is removed from a campaign.
Business outcome
---
You see which lapsed customers are still being mailed, so the wrong messages can be stopped without anything being changed by accident.
scenario
-
Marketers often export paying customers from the billing system and compare them to the email list by hand. Buyers who never made it into Drip miss the nurture campaigns, and it is easy to re-add someone who has already opted out.
What popdock provides
--
Name a product (or leave it open) and how many subscriptions to look at, and it reads active subscriptions from 2Checkout, then checks each buyer's email address in Drip. You get three lists: buyers missing from Drip, buyers who have unsubscribed, and a count of those present in both. Matching is on email only, and opted-out people are kept apart and never suggested for re-adding. Nothing is changed in either system.
Business outcome
---
You see which paying customers never reached Drip, and which opted out, so campaigns reach the right buyers without re-adding anyone who left.
scenario
-
Month-end cash reconciliation between the billing platform and the accounting system is usually done by eye across two exports. There is no shared payment number, so unmatched payments are found late, if at all.
What popdock provides
--
Give a date range, and optionally a currency, and it reads payments received in 2Checkout and invoice payments recorded in Rillet for the same window. It pairs payments with the same currency, the same amount and dates within 3 days, and labels every pair as a heuristic match. If one amount could pair with several rows it lists the candidates instead of choosing. You get totals by currency, the difference, and what is unmatched on each side. Nothing is changed in either system.
Business outcome
---
You see what does not reconcile between 2Checkout and Rillet for the period, with every match clearly labelled as a best guess.
scenario
-
Treasury staff tick off 2Checkout payouts against bank entries in Dynamics GP by hand. A deposit that is missing or duplicated can sit unnoticed for weeks, because each payout has to be searched for separately in the ledger.
What popdock provides
--
Give a start date for payouts, and optionally a checkbook, and it reads the completed payouts from 2Checkout. For each one it looks in Dynamics GP for a bank transaction of the same amount from 3 days before to 7 days after the payout date, skipping voided transactions. You get a table of matched and unmatched payouts, with the unmatched total per currency. If one transaction could fit two equal payouts, both are flagged as ambiguous. Nothing is written to either system.
Business outcome
---
You see which 2Checkout payouts have no matching deposit in Dynamics GP, so missing money is caught in days rather than weeks.
scenario
-
To tell whether a billing customer is the same person as a CRM contact, someone searches 2Checkout and Salesforce by hand. Different spellings or a second email address send them to the wrong record, or to none at all.
What popdock provides
--
Give a customer email address and it looks up the customer in 2Checkout, then finds the matching Salesforce contact and the contact's account. A side by side table shows first name, last name, company, city and email in each system, marked Match or Differs. If more than one 2Checkout customer shares the email it lists them and stops, and if Salesforce has no match it says so instead of guessing. Company names that differ only in case, punctuation or a suffix are called a likely match. Nothing is changed.
Business outcome
---
You know in one answer whether a 2Checkout customer and a Salesforce contact are the same person, and exactly which fields disagree.
scenario
-
Answering one question about a customer means opening the billing system and the email system side by side. Agents miss that the person has unsubscribed, or that their plan has lapsed, because the facts live in two places.
What popdock provides
--
Give a customer email address and it looks the person up in 2Checkout, falling back to leads if they are not yet a customer, then reads their subscriptions. It finds the same email in Constant Contact and reads their lists and recent activity. You get one profile covering identity, billing, marketing permission and engagement, plus a short list of mismatches between the systems. If the email matches several records it lists them and stops, and where names are spelled differently it shows both. Nothing is changed in either system.
Business outcome
---
Support agents answer billing and email questions from one profile, including whether the person is unsubscribed or on a lapsed plan.
scenario
-
Reps check 2Checkout for what a customer pays for and Pipedrive for the sales history, one screen at a time. Customers with an active subscription but no deal or recent activity slip through because nobody sees both views together.
What popdock provides
--
Give a customer email address and it finds the customer and their subscriptions in 2Checkout, then the matching person in Pipedrive, with the organization, deals and recent activity. You get a subscriptions table, the Pipedrive person, a deals table and an activity list, and customers with an active subscription but no open deal or no activity are flagged. If several customers or people match it lists them and stops, and where names differ it shows both without picking one. Nothing is changed.
Business outcome
---
Reps see billing and sales context in one view and spot active customers with no open deal or recent contact.
scenario
-
Account managers check which subscriptions expire soon in the billing system, then hunt through the CRM for open cases and deals to judge which renewals are at risk. Repeating that for dozens of subscriptions is slow and often skipped.
What popdock provides
--
Give a number of days (30 by default), and optionally a product, and it reads active 2Checkout subscriptions expiring in that window, up to 25 at a time. For each subscriber it finds the Dynamics 365 Sales contact and account, then counts open support cases and open opportunities. Each subscription is rated High, Medium or Low renewal risk, and Unknown when there is no CRM record, rather than a guess. Nothing is changed in either system.
Business outcome
---
Account managers see which expiring subscriptions are at risk and why, with unknowns clearly separated from low risk.
scenario
-
Finance staff compare the 2Checkout customer list against Intacct customers by hand. Customers who were never created in Intacct, or whose details have drifted, are found only when an invoice cannot be raised.
What popdock provides
--
Give an email, company or last name to filter by, and how many customers to check, and it reads the matching customers from 2Checkout. It looks each one up in Intacct by email first and then by a unique name match. If two or more Intacct customers fit, it lists them and marks the customer ambiguous rather than choosing. You get a table with a verdict for each customer: matched, missing, ambiguous, or matched with differences in email, city or country. Nothing is changed.
Business outcome
---
Finance sees which 2Checkout customers are missing or different in Intacct before an invoice runs into the gap.
scenario
-
Billing customers and CRM contacts are kept in two systems by hand. Customers go missing from the CRM or sit there under a different email, and nobody finds out until a renewal is missed.
What popdock provides
--
Give a company name to filter by and how many customers to check, and it lists the matching 2Checkout customers. Each is looked up in Capsule CRM by email first, then by company name. You get a table showing each customer as matched, probable (company only) or missing, with the Capsule CRM contact and owner, plus any company matches whose email differs from the billing email. Customers with no email are marked as having nothing to match rather than guessed at. It says when results were capped, and changes nothing.
Business outcome
---
Operations teams see which billing customers are missing or filed under a different email in Capsule CRM before a renewal slips.
scenario
-
Marketing exports customers from the billing system and contacts from the email platform, then compares them in a spreadsheet. The lists drift, and paying customers never get mailed while contacts who never bought stay on the list.
What popdock provides
--
Name a company (optional) and how many customers to read, and it reads 2Checkout customers, then looks each email up in Constant Contact. It also checks Constant Contact contacts that were not in the customer sample against 2Checkout. You get four lists: matched customers with any name mismatch, customers missing from Constant Contact, contacts who are not customers, and customers skipped for having no email, with counts. If an email matches several records it lists them rather than choosing, and it states that the contact check is a sample. Nothing is changed.
Business outcome
---
Marketing sees which customers are missing from Constant Contact and which contacts are not customers, without building a spreadsheet.
scenario
-
Finance compares 2Checkout customers with Business Central customers by hand. Mismatched names, locations or credit limits go unnoticed until an invoice goes to the wrong place or a blocked customer keeps ordering.
What popdock provides
--
Give a customer email address and it finds the customer in 2Checkout, falling back to leads, and the customer in Business Central, by email and then by company name. It compares name, company, city, country and credit limit, ignoring differences in case, spacing and punctuation. You get a table of each field marked Match or Differs, and a line saying whether the customer is in both systems or one. If several records match it lists them and stops, and format differences such as US versus United States are noted, not called errors. Nothing is changed.
Business outcome
---
Finance sees exactly which fields differ between 2Checkout and Business Central for a customer before an invoice goes astray.
scenario
-
Marketing exports customers from the billing system and contacts from the CRM, then compares them in a spreadsheet. Records drift, so paying customers are missing or mislabelled in HubSpot, and contacts who never bought stay in the database.
What popdock provides
--
Name a company (optional) and how many customers to read, and it reads 2Checkout customers, then looks each email up in HubSpot, including lifecycle stage and contact owner. It also checks HubSpot contacts that were not in the sample against 2Checkout. You get four lists: matched customers with any name or company mismatch, customers missing from HubSpot, contacts who are not customers, and customers skipped for having no email, with counts. If an email matches several records it lists them rather than choosing, and says the contact check is a sample. Nothing is changed.
Business outcome
---
Marketing sees which paying customers are missing from HubSpot and which contacts are not customers, with no spreadsheet work.
scenario
-
Finance exports customers from the billing platform and from the accounting system and compares them in a spreadsheet. Customers exist in one system and not the other, and invoices cannot be raised until someone notices.
What popdock provides
--
Name a company (optional) and how many customers to read, and it reads 2Checkout customers and the customers and email addresses held in Rillet. Customers are matched on email address, compared case-insensitively after trimming spaces. You get four lists: matched customers with any name or country mismatch, 2Checkout customers missing from Rillet, Rillet customers outside the sample, and customers skipped for having no email, with counts. If one email maps to several Rillet customers it lists them rather than choosing. Nothing is changed in either system.
Business outcome
---
Finance sees which billing customers have no Rillet record, so invoices are not held up by a gap found late.
scenario
-
Finance matches 2Checkout orders to Business Central invoices line by line in spreadsheets. Orders that were never billed, or were billed for the wrong amount, are usually found at month end.
What popdock provides
--
Give an order reference, or a date range (the last 7 days by default), and it reads the order or orders from 2Checkout, skipping test orders. For each it looks for the Business Central posted sales invoice, and then for an unposted document. It compares the amount and currency and classifies each order as matched, amount differs, currency differs, billed but not posted, or missing. Differences under a cent count as rounding, and tax differences are shown for review rather than called errors. Nothing is changed.
Business outcome
---
Finance sees which 2Checkout orders were never billed or were billed differently in Business Central, long before month end.
scenario
-
Accountants tick 2Checkout payouts against bank deposits in Intacct by hand. A payout that never reached the ledger goes unnoticed until month end, and currency differences make the comparison harder.
What popdock provides
--
Give a date range (the last 30 days by default) and an allowed amount difference (0.01 by default), and it reads the completed payouts from 2Checkout. For each it searches Intacct deposits in a window from 3 days before to 7 days after, then other receipts if no deposit fits. You get a table of each payout with the Intacct record found and a verdict: matched, amount differs, or not found. If a payout is in a different currency from the Intacct base currency it is reported as not comparable instead of guessing a rate, and several fits are listed as ambiguous. Nothing is changed.
Business outcome
---
Accountants see which 2Checkout payouts have no Intacct deposit, with no exchange rate guessed along the way.
scenario
-
Treasury ticks 2Checkout payouts against bank ledger entries by hand. A missing or short receipt in Business Central is spotted weeks late, and fees and refunds make it hard to see what a gap is made of.
What popdock provides
--
Give the approximate payout amount, a completed-from date and the bank account name, and it finds the payout in 2Checkout and the bank account in Business Central. It then searches ledger entries from 3 days before to 7 days after the payout for the receipt. You are told whether the payout is matched, matched with a difference, or not found, with the entries considered and the 2Checkout fee and refund totals. If several payouts or ledger entries fit it lists them and does not choose, and it never compares amounts across currencies. Nothing is changed.
Business outcome
---
Treasury sees whether a 2Checkout payout reached the Business Central bank ledger, and what fees or refunds may explain a gap.
scenario
-
Product lists drift between billing and the CRM, and finding the gaps means comparing two exports by eye. Products sold in 2Checkout may be missing from Dynamics 365 Sales, or enabled on one side and inactive on the other.
What popdock provides
--
Optionally give part of a product name, and it reads the 2Checkout products and the Dynamics 365 Sales products, up to 200 from each. It matches them on name, ignoring case and punctuation, and counts a product code equal to a CRM product ID or name as a match. You get three lists: products only in 2Checkout, products only in Dynamics 365 Sales, and matched products that are inconsistent, such as enabled in billing but not active in the CRM, with counts. Fuzzy matches are labelled possible matches, and a warning shows when a list may be cut off. Nothing is changed.
Business outcome
---
Operations sees which products exist on one side only or disagree between 2Checkout and Dynamics 365 Sales, with no manual comparison.
scenario
-
On a subscription, the customer and the end user can hold separate contact details. When they disagree, renewal emails reach the wrong person, and the mismatch is only found by opening each record and comparing them side by side.
What popdock provides
--
Give a subscription reference and it reads the customer, the end user and any additional information held on that subscription in 2Checkout. It compares email, name, company, country, city and phone, treating differences in case and spacing as matches. You get a side by side table with conflicts marked, the additional information entries, and a suggested owner for each conflict, offered as a suggestion only. If either record is missing it says which one and stops. Nothing is updated.
Business outcome
---
Support sees where a subscription's customer and end user disagree, so renewal emails go to the right person.
scenario
-
Account owners compare billing customers with CRM records across two systems by hand. Mismatched or missing records in Dynamics 365 Sales are missed, and the account and contact that belong to a customer take several searches to find.
What popdock provides
--
Give a customer email address and it finds the customer in 2Checkout, then the matching Dynamics 365 Sales contact and account, falling back to the company name when the email finds no account. A table compares name, company, city, country and phone, marked match, differs or missing, and states whether the customer is in both systems or in one only. It stops if 2Checkout has no customer or several, and treats an ISO country code and its matching name as the same. Nothing is changed in either system.
Business outcome
---
Account owners see in one answer whether a 2Checkout customer is in Dynamics 365 Sales and which details differ.
scenario
-
Chasing overdue 2Checkout invoices usually starts with an export, then a manual filter for part-paid items and a guess at which balance is oldest. When customers pay in different currencies, it is easy to total balances that should never be added together.
What popdock provides
--
Give a currency and a due date and it lists the unpaid accounting payments that fall due before then, keeping only rows with a balance above zero. It shows type, status, amount, balance and invoice links, ranks them by days overdue and totals the balance. Currencies are never combined, and the top five get their invoice files. Nothing in 2Checkout is changed or marked paid.
Business outcome
---
Collections start from a ranked list of overdue 2Checkout balances, per currency, without touching a single payment record.
scenario
-
Cross-sell and upsell campaigns in 2Checkout are set up in separate places, and each links to its own products. Campaigns that ran past their end date, have no products or recommend the same product twice tend to sit unnoticed until a customer sees an odd offer.
What popdock provides
--
Name a product code if you want to focus on one product, or review them all. It reads the cross-sell and upsell campaigns with their products and flags campaigns past their end date but still active, campaigns with no products, duplicate recommendations from the same master product, discounts above 50 percent and upsells that recommend something already included. You get a per-campaign summary. It only reads and never creates or changes a campaign.
Business outcome
---
Marketing gets a clear list of campaigns to fix or retire, found in minutes and with no risk to live offers.
scenario
-
Renewal reps build the list of expiring 2Checkout subscriptions from exports, then have to work out which customers renew automatically. The manual-renewal customers are the ones who lapse silently because nobody reminded them.
What popdock provides
--
Give a window in days, 30 by default, and optionally a product code. It lists subscriptions expiring in that window, then checks each one for automatic renewal and its manual renewal link, looking up the next renewal price for at-risk rows. Results are grouped into auto-renewing (a count only), manual renewal needed with email and link, and disabled but still expiring. It never renews anything or contacts a customer.
Business outcome
---
Renewal reps get a short list of the customers who need a manual push, with the link, before the subscriptions lapse.
scenario
-
Before creating a new lead in 2Checkout, a rep has to know whether one already exists for that billing email or code. Without a quick search, the same buyer ends up with several leads and nobody knows which was used.
What popdock provides
--
Give a billing email or a lead code and it searches 2Checkout leads accordingly. For each lead it shows the code, billing name, email, company, city, country, currency and where it was generated from. It also counts how many leads exist for the same email, so you can see duplicates before creating another. It only reads, and it never marks a lead used or edits it.
Business outcome
---
Reps know in seconds whether a lead already exists, so they stop creating duplicates.
scenario
-
Orders waiting on approval in 2Checkout are usually found by scrolling the order list. High-value ones can sit unreviewed, and totals are easy to get wrong when test orders and several currencies are mixed together.
What popdock provides
--
Give an approval status and a minimum gross price and it lists matching orders ranked by value. The ten largest also get their items, so you see what was bought. You get a table with buyer, currency, discounted price, status and items, with exposure totalled per currency and never added across currencies. Test orders are left out of totals and listed separately. Nothing is approved, cancelled or refunded.
Business outcome
---
Finance reviews the biggest pending orders first, with clean per-currency exposure and no accidental approvals.
scenario
-
In 2Checkout, partners, resellers and affiliates sit in separate screens. A partner that is inactive, has no resellers or has resellers with no email is easy to miss, and so is an affiliate account that duplicates the partner.
What popdock provides
--
Give a partner code and it reads the partner profile (status, company, country, currency, proforma permission), then the resellers under it and any affiliate whose name contains the partner company name. You get the profile, a reseller table and flags for a partner that is not active, no resellers, resellers missing email and a possible affiliate duplicate. If the partner is not found it stops. It never edits a partner, reseller or affiliate.
Business outcome
---
Operations spots inactive or incomplete partner setups in one pass, without opening three screens or editing anything.
scenario
-
Payout reconciliation in 2Checkout spans a balance report and a list of payouts. Reserves, processing fees and chargeback fees are held in different places, so the balance rarely ties out at a glance, and mixed currencies make it worse.
What popdock provides
--
Give a currency such as USD or EUR and it reads the payout balance, noting orders total, fees, tax, affiliate commission and the reserve and dispute balances. It then lists the payouts with status, type, amount, fees, refunds and transfer date. You get the balance table, recent payouts, any payout that is not completed, and the reserves and chargeback fees held. Currencies stay separate. Nothing is initiated or changed.
Business outcome
---
Finance sees balance, reserves and payouts side by side for one currency, ready to reconcile, without risk to any payout.
scenario
-
Open 2Checkout proposals are often tracked in spreadsheets, so stale ones and proposals that keep getting revised go unseen. Nobody notices a proposal untouched for a month, or one where the bill-to and sell-to companies do not match.
What popdock provides
--
Give a start date, 90 days back by default, and optionally a status. It reads the proposals created since then, then counts how many versions each one has been through. You get proposals not updated in 30 days and not in a final status, oldest first, proposals with three or more versions, proposals where bill-to and sell-to companies differ, and a count per status. It only reads and never sends, locks or edits a proposal.
Business outcome
---
Sales leads see which proposals have gone stale or churned through versions, with nothing sent or locked on their behalf.
scenario
-
To understand one 2Checkout subscription, a support agent opens payment, renewal, pause, history and usage screens one after another. A card expiring before the subscription ends, a disabled renewal or a pending 3DS step is easy to miss.
What popdock provides
--
Give a subscription reference and it first confirms the subscription exists, stopping if the reference is not found. It then reads the subscription row with its card details, renewal setting and next renewal price, any pause and its resume date, and usage records. You get a one-line verdict of Healthy, At risk or Broken, key dates, risk flags and a recommended next action. Items with nothing are marked no records. It never changes the subscription.
Business outcome
---
Support agents get a verdict and a next action for one subscription without hopping between screens.
scenario
-
Reps quoting a 2Checkout upgrade often cannot see what the subscription can move to, or what the next renewal will cost. Without both numbers side by side, a quote can be wrong, and options in the same group cannot be combined.
What popdock provides
--
Give a subscription reference, and a currency if you want one. It reads the upgrade options available to that subscription, with product, price type, net and gross price and group. It then reads the current renewal price. You get a table from cheapest to dearest with the difference from the renewal price, and a note of which options share a group and so exclude each other. It states clearly that no upgrade was performed.
Business outcome
---
Reps quote upgrades with the real options and the renewal price in front of them, and no upgrade is triggered by accident.
scenario
-
Support and credit control answer one question by opening two systems: does a customer who owes money in Business Central still have live 2Checkout subscriptions? The two views disagree, and a customer can be blocked in finance while still being served.
What popdock provides
--
Give a customer email and a look-back in days, 90 by default. It reads their subscriptions and customer record in 2Checkout, then their balance, balance due, credit limit, blocked status and recent ledger entries in Dynamics 365 Business Central. You get the subscription list, the Business Central position and a risk note, flagged when active subscriptions meet a blocked account or balance due. Currencies are shown side by side, never added, and it matches on email only. Both systems are read only.
Business outcome
---
Support and credit control share one view of what a customer subscribes to and owes, with risky combinations flagged.
scenario
-
Renewal and billing teams chase expiring 2Checkout subscriptions without knowing the customer already owes overdue invoices in Intacct. A renewal call lands badly, or a credit problem is missed, because the accounting side was never checked.
What popdock provides
--
Give a window in days, 30 by default, and a subscription status, Active by default. It lists the 2Checkout subscriptions expiring in that window, looks up each customer, then finds the matching customer in Intacct with their total due and credit limit and lists open invoices where something is owed. You get only customers with a balance, their expiring products, oldest open invoice and credit limit position. Customers not found are listed separately, never as zero. Nothing is changed in either system.
Business outcome
---
Renewals are chased with the customer's overdue Intacct balance in view, and unmatched customers are never mistaken for clear accounts.
scenario
-
Unsubscribes are reviewed in Mailchimp with no view of who is a paying customer. A person who just opted out of a campaign may hold an active 2Checkout subscription, yet gets treated like any cold contact.
What popdock provides
--
Name a Mailchimp campaign and a look-back in days, 30 by default. It reads the unsubscribes from that campaign, stopping if more than one campaign matches, then looks each email up in 2Checkout and keeps those with an active subscription. You get a table with email, unsubscribe date, reason, product and expiry date, plus a count of unsubscribers with no 2Checkout record. It only reads, matches emails ignoring case and never suggests resubscribing anyone.
Business outcome
---
Support can handle opted-out paying customers with care, because the overlap between Mailchimp unsubscribes and 2Checkout subscribers is clear.
scenario
-
Dispute reviewers piece a customer's history together from two systems. A Stripe dispute shows the charge but not the subscription behind it, and with response deadlines running, it is easy to miss a due date.
What popdock provides
--
Give a customer email. It finds the Stripe customer, stopping if there is no match or more than one, then lists their disputes with reason, amount, status and due date, and reads the charge behind each. It then adds the 2Checkout customer and subscriptions for the same email, noting when there is no 2Checkout match. Disputes due within 7 days are highlighted. It only reads, and nothing is changed in Stripe or 2Checkout.
Business outcome
---
Reviewers see each Stripe dispute with its charge and subscription context in one place, with urgent deadlines highlighted.
scenario
-
Support cannot tell that a subscribed 2Checkout customer also owes money in NetSuite without logging into both systems. A customer can keep a live subscription while invoices go unpaid, and nobody sees the pattern.
What popdock provides
--
Give a customer email. It reads the customer's 2Checkout subscriptions with product, status, expiry and currency, then finds the NetSuite customer, notes their balance and lists unpaid invoices with document number, date, total and unpaid amount. You get the subscriptions, the invoices, the balance and a one-line risk call: subscribed and owing, subscribed and clear, or lapsed and owing. If there is no NetSuite customer it says so, and with no subscriptions it reports only NetSuite. Both systems are read only.
Business outcome
---
Support gets a clear collection-risk call for a customer without logging into both systems.
scenario
-
Tracing a 2Checkout order to its items, invoice and customer takes several lookups, and orders cannot be searched directly by every reference. Searching by a common last name returns several orders, and the wrong one is easy to pick.
What popdock provides
--
Give the buyer last name or the external reference the merchant stored. It finds the matching order, trying the external reference first, and lists reference, billing name, status, approval status, currency, discounted price and test flag. If several orders match, it shows them and stops so you can pick one. For the chosen order it pulls the items and the invoice. Test orders and orders not approved are flagged. It only reads and changes nothing.
Business outcome
---
Support traces one order to its items and invoice in a single request, without picking the wrong order from a list.
scenario
-
Accountants hunt for a 2Checkout order's invoice in Dynamics GP by searching customer names and amounts. Orders that never posted are missed, and test orders create false alarms when no document exists.
What popdock provides
--
Give a 2Checkout order reference and optionally a look-back in days, 60 by default. It reads the order and its items in 2Checkout, stopping if it is not found, then searches Dynamics GP sales documents by customer PO number within the date window, falling back to receivables transactions. You get the order and each matching GP document, the difference in amount and a verdict of Match, Differs or Currency not comparable. Test orders are flagged. Both systems are read only.
Business outcome
---
Finance confirms whether a 2Checkout order reached Dynamics GP and whether the amounts agree, without searching by name.
scenario
-
Finding the NetSuite invoice for a 2Checkout order means searching both systems by hand and checking the totals. A matching invoice might be a cash sale instead, and a different currency can make a match look wrong.
What popdock provides
--
Give a 2Checkout order reference and optionally a look-back in days, 30 by default. It finds the order, then the NetSuite customer by billing last name, asking you to choose if several match. It searches that customer's invoices in the date window, trying the external reference as the document number, and falls back to cash sales. You get whether the order, customer and document were found and whether the totals match in the same currency. Differences are reported, never converted. Both systems are read only.
Business outcome
---
Finance sees whether an order has a matching NetSuite invoice or cash sale, and whether the totals agree, in one request.
scenario
-
When a customer disputes a payment, staff search 2Checkout for the order, then Intacct for the invoice and the receipt. Matching the wrong customer is common, and it is hard to say whether an order was ever invoiced or paid.
What popdock provides
--
Give a billing last name and optionally the 2Checkout external reference. It finds the order, listing candidates and stopping if more than one matches, then finds the Intacct customer, stopping if none matches rather than guessing. It looks for the invoice near the order date, then the AR payment, and notes what was paid and when. You get the order, customer, invoice and payment, with a verdict of Paid, Invoiced and unpaid, Not invoiced or Customer not found in Intacct. Currency differences are flagged. Both systems are read only.
Business outcome
---
Finance can answer whether a disputed 2Checkout order was invoiced and paid in Intacct, without matching the wrong customer.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.