Systems Integration: How AppWT Connects Payments, Print and Email

Systems Integration Payments Print on Demand Transactional Email

Why AppWT Is Its Own Case Study

Most of AppWT's client work is confidential. AppWT's own store is not, so this page uses it to show how AppWT connects separate systems into one working process. Every fact here comes from AppWT's own code, test records and audit logs.

The Systems Being Connected

• AppWT Manuals. AppWT's own online store of operator guides, sold as instant PDF downloads and printed paperbacks.
• Stripe. Takes the payment and sends AppWT a signed message, called a webhook, when the payment changes.
• A pricing database. Holds the one approved price for each title.
• A delivery ledger. A database table that records each payment the store has delivered.
• A print-on-demand provider. Prints and ships each paperback, reached through its API.
• Postmark. Sends the customer emails, such as the message with the download link.
• An email language check. Reviews customer emails written in more than one language and records the result.

How One Order Moves Through the System

1. The price is checked before the charge. The database names the price, and the product page must show that same price. If the two disagree, or the page price cannot be read, the sale is refused. The amount sent by the buyer's browser is never used.
2. Stripe's message is verified. Each webhook carries a signature, and the store checks it before it reads anything else. A message with a bad signature is rejected.
3. Only paid orders are delivered. The store delivers when Stripe reports the order as paid, or as needing no payment because a full discount code applied. A bank payment that has not cleared waits for Stripe's later message that it succeeded.
4. A refusal still answers Stripe. When the store decides not to deliver, it still sends Stripe a success code. Otherwise Stripe would keep sending the same message again.
5. The database allows one delivery per payment. The ledger uses Stripe's payment ID as its unique key. The first message for a payment claims it, and the database itself refuses any later claim for the same payment.
6. The buyer gets one email. A cart with several books produces one email with a download link for each book, sent through Postmark.
7. Print orders go into a queue. The payment handler never calls the print provider itself. It writes the paid order to a queue file named for the payment, so a repeat replaces that file instead of adding a second order. A separate worker checks the queue every 5 minutes and places the print job.
8. The print worker has its own guards. It runs only after payment clears. It measures the page count and price itself instead of trusting a number passed to it, and it records the order before it calls the provider, so a crash leaves a claimed record and not a free reprint.
9. A paid order is never dropped. If a print order arrives without a complete shipping address, it is logged as paid and flagged for a person to finish by hand.

Two Defects Found While Connecting Print

Connecting the print step meant reading the existing payment handler closely. That review found two defects that were already live. Neither one was about printing, and both were about money.

• Delayed payments were delivered before they cleared. Stripe first reports some payment methods, such as a bank debit, as complete but unpaid. The handler did not check the payment status, so it sent the book anyway. With print connected, that would have shipped a physical book for an order that had not paid.
• One purchase was delivered twice. A single purchase raises two Stripe events, and the handler acted on both of them. Each sale created two download links and sent two emails.

The fixes are the payment status check, the payment ID key and the database rule in the list above. Reading the ledger first and then writing to it was not enough, because two Stripe messages can arrive at the same moment. Letting the database refuse the second write closes that gap.

Stripe No Longer Waits on the Email Check

Before this change, a payment webhook ran the email language check before it answered Stripe. That check loads a page from the AppWT website and allows up to 25 seconds for an answer. If the website was slow, Stripe waited that long for its reply, and a slow reply is how retries and duplicate orders start.

Now the webhook answers Stripe first. The same email check still runs on the same message, right after the reply goes out. On servers that cannot finish a reply early, the check starts in a separate background process instead.

AppWT tested this against a simulated slow website that accepts a connection and never answers. The test made no real payments and sent no real email. Before the change, payment replies took about 25 seconds. After the change, they took under half a second, and the email check still recorded its result. The same test now runs every day.

Email That Keeps Its Original Links

Postmark is AppWT's approved service for outgoing email, and link tracking is turned off on every message. Link tracking rewrites each link so it passes through a tracking address first. A person who needs to copy or look up a link from an AppWT email should get the real link, not a rewritten one.

AppWT first turned link tracking off in its own sending tool and added a guard that refuses any send that asks for it. A sample of 100 recent messages then showed that 86 still went out with tracked links. Website forms, plugins and other systems reached the mail service by their own routes, and those routes used the mail server's default setting, which had tracking on.

The fix was to turn tracking off in the mail server's own setting, which every route passes through, and to check that setting and recent messages every day. An audit on October 25, 2026 found 1,344 of 1,344 messages from the past seven days sent with link tracking off. A check on October 31, 2026 found the server setting still off and no tracked link in the latest 100 messages.

The lesson applies to any integration. Guarding the paths you use yourself is not the same as guarding the system, so the control has to sit on the path that carries the volume.

Key Numbers

Honest Status

This page describes AppWT's own store and mail. It is not a client result, and it does not promise a result for any business.

The 25-second figure comes from a controlled test that simulates a slow website, not from a recorded outage. The email figures come from AppWT's own audits on the dates shown. A second, separate monitor for the payment reply test is still being added.

No set of controls removes every risk. That is why the payment reply test and the link tracking check both run again every day.

What This Means for Your Business

If your business runs payments, orders, fulfillment and email in separate tools, AppWT can connect them with the same controls it uses on its own store. Those controls are verified webhooks, one delivery per payment enforced by the database, slow steps in a queue and email that keeps its original links. See API development and integration, payment integration, email automation setup and enterprise automation and AI systems. The store on this page is live at AppWT Manuals.