A good beginning.
A beautiful app.

01 / START WITH A CONNECTION

Your first connection

WooApp uses the WooCommerce store you already manage. Your developer connects that store at build time. Shoppers open your app and see your store directly; there is no store selector or demo mode in customer builds.

1. Unzip your complete download. Locate the inner plugin ZIP and Flutter source ZIP. Keep the plugin ZIP compressed for WordPress.
2. Prepare the store. Confirm the requirements, products, stock, shipping and policies on a staging copy first.
3. Upload and activate the plugin. Use Plugins → Add Plugin → Upload Plugin, then open WooApp → WooApp. Look for Setup: Ready.
4. Check the public connection. Visit https://your-store.com/wp-json/wooapp/v1/bootstrap. A JSON response with data.api_version, data.features.native_auth: true and data.checkout.ready: true confirms discovery.
5. Set up Flutter and preview. Extract the Flutter source, open its mobile folder and run the commands below with your real store URL.
6. Personalize and test. Update branding and home content in WordPress, then refresh the app. Configure payment accounts and test signed native builds before submitting to the stores.

flutter pub get
flutter run -d chrome --web-port 8090 --dart-define=STORE_URL=https://your-store.com

02 / THE RIGHT FOUNDATION

Requirements & compatibility

Use the compatibility requirements below to prepare your store and development tools. Keep a staging copy for store upgrades and merchant-specific customizations.

Supported commerce scope

WooApp supports simple and variable physical products, English and left-to-right layouts. Catalog search, sorting and pagination, galleries, variations, favorites, cart, coupons, delivery, customer accounts and order history are implemented. Checkout currently uses one address for both billing and delivery.

Store APIs must be reachable without an administrator login. Security plugins, firewalls and caching layers must permit customer bearer sessions, WooCommerce cart tokens and checkout requests. Keep customer and checkout responses out of public caches.

03 / A PLACE FOR EVERYTHING

Inside your download

The complete buyer download contains the source archive, installable plugin and this offline handbook. Extract the outer archive on your computer. Upload only the inner WordPress plugin ZIP to WordPress.

wooapp-2.0.0/
├── START-HERE.html
├── documentation/
│   ├── index.html
│   ├── docs.css + docs.js
│   └── assets/                 # Screenshots, fonts and diagrams
├── wordpress-plugin/
│   └── ultimate-app-api-2.0.0.zip
├── flutter-source/
│   └── wooapp-flutter-2.0.0.zip
├── RELEASE-NOTES.txt
└── SHA256SUMS.txt

Extracting the Flutter ZIP gives you mobile/, with Android and iOS projects, Flutter source, assets, tests and the locked dependencies. It does not contain installed dependencies, local environment files, signing keys, developer credentials or compiled APK / IPA files. Those are generated for your own app identity.

04 / THE WORDPRESS SIDE

Install the WordPress plugin

1. Prepare a backup and staging store. Confirm your store’s supported WordPress, WooCommerce and PHP versions.
2. Sign in to WordPress as an administrator. Open Plugins → Add Plugin and choose Upload Plugin.
3. Select the inner ZIP. Choose wordpress-plugin/ultimate-app-api-2.0.0.zip from your extracted buyer download. Do not select the entire buyer download or the Flutter ZIP.
4. Choose Install Now, then Activate Plugin. In the plugin list, the display name is Ultimate App API. The merchant menu is WooApp.
5. Check the setup status. Open WooApp → WooApp. It should report Setup: Ready. Resolve dependency or schema errors here before continuing.
6. Verify discovery. Visit your store’s /wp-json/wooapp/v1/bootstrap endpoint. If routing fails, review Settings → Permalinks, the web server and security restrictions.

Know your WooApp menu

If a host blocks browser uploads, ask the host to install the plugin folder under wp-content/plugins/ultimate-app-api/, then activate it in WordPress. Preserve the folder name. Upload-limit changes belong to hosting/PHP settings, not the Flutter app.

05 / ONE ADDRESS. YOUR WHOLE STORE.

Connect the app to your store

Your developer supplies STORE_URL when running or building the Flutter app. Use the canonical public HTTPS address of the WordPress installation, including a subdirectory if WordPress lives in one. Do not append /wp-admin, /wp-json or an endpoint.

1. Open the connection endpoint in your browser. Replace the example domain below with your WordPress address. A data envelope with the store and feature configuration should load without logging in.
2. Use the final URL after redirects. Check HTTPS and www/non-www choices. The app avoids following unexpected API redirects; do not rely on a redirect to correct an incorrect store address.
3. Run the app with the same base URL. Set the flag on every run/build, or use your own private build script to supply it consistently.
4. Refresh the app home after WordPress edits. Branding and collections load from the store. Switching the destination store requires a new app build.

https://your-store.com/wp-json/wooapp/v1/bootstrap

flutter run -d chrome --web-port 8090 --dart-define=STORE_URL=https://your-store.com
flutter build apk --dart-define=STORE_URL=https://your-store.com
flutter build ipa --dart-define=STORE_URL=https://your-store.com

The ipa command requires macOS and signing setup. The apk command above is a build recipe, not a claim that your release is already signed for Google Play. Follow the platform release sections.

Browser preview and CORS

A browser-served Flutter app needs permission from your store to make cross-origin REST requests. Configure an exact preview origin at the web server or in a host-maintained WordPress integration. Allow Authorization, Content-Type, Cart-Token and Idempotency-Key, allow preflight requests, and expose Cart-Token. Avoid wildcard access for authenticated customer endpoints. The bundled WordPress plugin does not automatically grant arbitrary preview origins.

The development Docker store already permits the local Flutter origin on port 8090 through a separate, development-only MU plugin. That development helper is not included in the buyer’s installable plugin. The website showcase runs at port 8091 but embeds its app through the same-origin /demo/ path; its local development origin is also explicitly allowed.

If the URL is missing or unreachable

An unset URL displays a configuration error. An unreachable or incompatible store displays an error and retry control. An empty store displays the normal empty catalog. Customer builds contain no demo catalog and offer no connection selector.

06 / MAKE IT UNMISTAKABLY YOURS

Logo, colors & typography

Open WooApp → General settings. This page changes the in-app storefront header and visual theme; it does not change the installed app’s launcher icon, package name or operating-system display name.

1. Upload your logo. Choose Change logo and use the WordPress media library. A transparent PNG or WebP works well for a wordmark. Without a selected logo, the store name is used.
2. Set its size. Adjust Logo height (24–88 px) and Maximum logo width (80–240 px). Both act as constraints so the image keeps its aspect ratio. Preview the result at narrow phone widths.
3. Write your header tagline. Keep it short and readable. The field accepts up to 70 characters.
4. Choose a font style. Editorial pairs DM Sans with Cormorant headings. Modern sans uses DM Sans throughout. System sans follows the platform’s default font.
5. Select a complete palette. Olive & citrus, Coastal blue, Soft rose, Warm earth, Lavender dusk and Quiet monochrome coordinate the background, text, buttons, borders and accents.
6. Save settings. Refresh the app home to retrieve the updated branding. If the page says settings changed elsewhere, reload it and apply your edits to the latest saved version.

App name, icon and splash

For your own release, set the Android application label in android/app/src/main/AndroidManifest.xml and iOS CFBundleDisplayName in ios/Runner/Info.plist. Replace Android launcher/adaptive assets and the iOS AppIcon asset set with your brand’s platform-specific exports. The included tool/generate_brand_assets.dart generates WooApp’s monogram; customize it before using it for another brand. Review launcher and splash assets on a real device. The initial app splash uses a neutral white background.

07 / CURATE A HOME WORTH OPENING

The visual home builder

Open WooApp → Home builder. The app keeps its header, hero banners and category strip above the product collections you curate here.

1. Add a section. Choose + Add section. Give the collection a descriptive title and, optionally, a subtitle.
2. Choose the layout. Grid gives you two columns; Carousel creates a horizontal product rail; Compact list gives each item a clear row. Mix layouts to vary the page rhythm.
3. Search for products. Type a product name or exact SKU in the product search. Select the matching products instead of looking up IDs. Use the next-page control when more matches are available.
4. Arrange the collection. Drag selected products or use the move arrows. Remove an item from the section without deleting the WooCommerce product.
5. Arrange the page. Drag sections in the left list or use their up/down arrows. Toggle Visible in app to hide a collection while keeping its saved configuration.
6. Save home page. Refresh the app. The preview is a layout guide; the real app resolves current product data and prices from WooCommerce.

Limits: up to 20 sections and 100 products per section. Use smaller, focused collections for a better first screen. When no usable collection layout is configured, the app can show its latest-products collection. A missing or empty store is never replaced with a bundled demo catalog.

08 / SET THE SCENE

Image & video banners

Open WooApp → Banners. The order in the left panel is the order customers see in the hero. Make a video banner the first item if you want motion to lead the home page.

1. Add a banner. Choose + Add banner. Enter a headline, supporting text and small label, keeping text short enough for a phone.
2. Choose Image or Video. Select your image through the media library. For a video, select both the video file and a poster image. The poster is shown while loading, when motion is reduced, or when playback cannot start.
3. Give it a destination. Choose no link, a product, a category or a store search. Product/category destinations use search selection; no manual ID is needed. Add a short button label.
4. Set visibility and order. Drag the banners or use the move controls. Only the active slide’s video plays. You can duplicate a banner to create a related story.
5. Save banners. Refresh the app and test every destination. Saved banner removals can be found in WordPress Trash.

Media that loads well

Choose sharp, compressed images with a clear focal point. Hero images are cropped to fill their frame, so keep essential details away from the edges. H.264 MP4 is a practical starting point for video; actual codec and autoplay behavior depend on the device/browser. Keep hero clips short, compress them, use HTTPS media URLs and provide a readable poster.

Videos begin muted and loop on the active slide. They pause when hidden or when leaving the route. Reduced-motion users initially see the poster and may play explicitly. Customers control slides through swipes, dots or arrows; there is no timed slide rotation. Test slow loading and playback failure as well as the happy path.

09 / YOUR STORE IS THE SOURCE OF TRUTH

Catalog, shipping & checkout

Prepare your products

1. Use published, visible products. Add meaningful descriptions, prices, category assignments and stock settings in WooCommerce.
2. Add good product images. The gallery uses the full product image list. Supply clear primary and gallery photos. Category thumbnails are managed under Products → Categories.
3. Finish your variations. Configure attributes, variation combinations, prices and stock. Verify that each intended choice can actually be purchased on the website and in the app.
4. Check promotions. Configure sale prices and coupons in WooCommerce; test eligibility, expiry and minimum spend with the app’s server-calculated totals.

Configure checkout in WooCommerce

Review WooCommerce → Settings for your currency, allowed selling/shipping countries, shipping zones and rates, tax rules, guest checkout, account creation and policy pages. In the app, entering an address prompts the server to calculate eligible delivery options. Rates may change the final total. No matching shipping rate must be resolved in the store, not bypassed by the app.

The cart displays product totals, discounts, shipping, named fees, tax and the final WooCommerce total. Stock limits and quantity restrictions apply. Coupons can be applied and removed with visible server errors. The current checkout collects one shared billing and delivery address.

Interrupted orders and recovery

If payment or the network is interrupted after an order attempt is retained, the app offers to resume that original attempt. Use that recovery action; do not create a new order just because a provider screen closed. The backend verifies provider status before treating an order as paid. Cash on delivery is recorded as unpaid at confirmation. Orders needing manual review are explicitly distinguished.

Customer accounts

The app supports store-enabled registration, sign-in, password recovery, profile changes, address book, order history, downloads, reviews and deletion requests. Customers sign in with their own account, not a WordPress administrator/store-manager account. Configure reliable WordPress email delivery for recovery and confirmation messages. Browser-preview sessions live only in memory and are cleared on reload.

10 / CONFIGURE THE FINAL TAP

Native payments

The current payment set is cash on delivery, Stripe and PayPal. WooApp → Native payments configures dedicated app adapters. Your website’s Stripe/PayPal plugins can coexist, but their settings are not automatically reused and their web checkout handlers are not called.

Cash on delivery

1. Open WooCommerce → Settings → Payments → Cash on delivery and enable it.
2. Review restrictions, including enabled shipping methods and order types.
3. Place a test order with an eligible address and shipping method. Confirm the resulting WooCommerce order and its unpaid COD status.

Stripe

1. Begin in a Stripe test environment. Obtain the publishable and secret API keys belonging to the same environment/account.
2. Register the store webhook endpoint. Use https://your-store.com/wp-json/wooapp/v1/webhooks/stripe. Subscribe to PaymentIntent success, payment failure and cancellation events: payment_intent.succeeded, payment_intent.payment_failed, payment_intent.canceled.
3. Configure WooApp. Set Stripe mode to sandbox, enter the publishable key, secret key and endpoint signing secret, then enable Stripe and save. All required values must be present for the adapter to be configured.
4. Configure the app return scheme. The source uses wooapp://safepay. If you rebrand it, update lib/core/payments.dart, the Android manifest and iOS URL types consistently.
5. Test the signed Android/iOS app. Cover success, 3DS, declined payments, cancellation, background/return, interrupted network and resuming an existing attempt. Verify signed webhooks and the final WooCommerce order.
6. Switch environments only for launch. Use matching live credentials and a live webhook endpoint/signing secret after confirming your store’s sandbox checkout flow. Repeat a controlled production verification.

The app displays Stripe PaymentSheet using a server-created PaymentIntent. The secret key stays on your server. A provider approval screen alone is not the final authority for the order’s paid status. Refer to Stripe’s PaymentIntents guide and webhook documentation for your provider-side setup.

PayPal

1. Create a PayPal sandbox REST app. Prepare the client ID and client secret plus sandbox buyer/seller accounts.
2. Register the store webhook. Use https://your-store.com/wp-json/wooapp/v1/webhooks/paypal. Register relevant checkout order and capture events, then copy that webhook’s ID.
3. Configure WooApp. Select PayPal sandbox mode, enter the client ID, client secret and webhook ID, enable it and save.
4. Review native return configuration. Android uses com.wooapp.wooapp.paypal in both MainActivity.kt and the manifest. Replace it consistently for your application ID and configure any provider-side app requirements. iOS approval is handled by the bundled PayPal bridge.
5. Verify approval and capture. The backend creates the PayPal order; the app approves that exact order and the backend captures/verifies it. Test cancel, duplicate taps, interruption and order recovery on both target platforms.
6. Prepare live accounts and webhook. Use corresponding live REST app values only after sandbox/native verification, then verify a controlled live order.

Provider reference: PayPal REST APIs, Orders v2 and webhooks.

Saving, clearing and server overrides

Blank secret inputs retain their previously saved value; the page does not echo secrets back. Clear stored secret credentials removes stored secret fields when saved. A matching private WOOAPP_* server constant overrides the UI and is shown as managed in server configuration. Mode, credentials and webhook configuration must match the same provider environment.

Another gateway?

Required gateway integration has no extra development charge. Contact item support with the provider’s official API/SDK documentation, intended country, currency, account type and your requirements. We will confirm technical feasibility and schedule. Account approval, provider fees and broader unrelated customization are separate.

11 / THE DEVELOPER’S DESK

Set up Flutter

1. Install Flutter. Follow the official Flutter installation guide for your operating system. This source was tested with Flutter 3.35.5 and Dart 3.9.2. Start with the included pubspec.lock; do not blindly upgrade dependencies before your first working build.
2. Install platform tooling. Android needs the Android SDK/tooling. iOS builds need macOS and Xcode. Chrome can be used for the initial browser preview.
3. Extract the source ZIP. Open the extracted mobile directory in VS Code or Android Studio. All commands in this chapter run from that directory.
4. Check your tools. Run flutter doctor -v. Resolve problems for the platform you plan to build. iOS warnings are expected on Windows; iOS cannot be built there.
5. Fetch the locked dependencies. Run flutter pub get. Keep pubspec.lock with your source.
6. Run checks and preview. Start with analysis and the included Flutter tests, then run the browser preview against your own configured store. Browser CORS must be set up for its origin.

cd mobile
flutter --version
flutter doctor -v
flutter pub get
flutter analyze
flutter test
flutter run -d chrome --web-port 8090 --dart-define=STORE_URL=https://your-store.com

Where to make changes

The site’s branding switcher is a preview tool. It changes only that embedded instance’s theme. Real customer builds use lib/main.dart and branding from WordPress. They contain no palette switcher, demo store selector or fallback demo catalog.

12 / YOUR ANDROID DEBUT

Build & release Android

Prepare your own application identity and release signing before building for Google Play. The source currently has preview signing configuration; replace it with your private release signing setup.

1. Choose your application ID. Replace com.wooapp.wooapp in android/app/build.gradle.kts (namespace and applicationId). Update the Kotlin package and its source-directory path consistently if you rename the namespace.
2. Name and brand the app. Change android:label in the main Android manifest. Replace launcher/adaptive icons with your own assets.
3. Update callback schemes. Keep the PayPal return scheme consistent between the manifest and MainActivity.kt. Update the Stripe scheme/return URL in the manifest and lib/core/payments.dart together. Provider account setup must match your app.
4. Create or select your upload keystore. Keep it outside the distributable source. Record its alias and passwords privately and back it up securely.
5. Configure Gradle signing. Create android/key.properties privately, load it in android/app/build.gradle.kts, create a release signing configuration and replace the generated debug signing assignment. Follow Flutter’s Android signing guide.
6. Set your version. Update version: 2.0.0+1 in pubspec.yaml to the version/build number you are releasing. The build number must increase for subsequent store uploads.
7. Build an app bundle. Use the command below with your production HTTPS store URL. An APK is useful for direct device testing; Google Play distribution normally uses the app bundle.
8. Test through an internal release track. Check the launch checklist, full cart/order flow and all enabled native payment callbacks. Verify the uploaded artifact is signed with your intended key.
9. Complete the store listing. Add accurate screenshots, app access instructions where required, support/privacy details, content rating, data declarations and all current Google Play requirements. Review the live console requirements at submission time.

flutter build appbundle --release --dart-define=STORE_URL=https://your-store.com
flutter build apk --release --dart-define=STORE_URL=https://your-store.com

# Typical outputs:
# build/app/outputs/bundle/release/app-release.aab
# build/app/outputs/flutter-apk/app-release.apk

Create your upload keystore

If you do not already own the upload key for this application, run this with your Java keytool and a private destination on your computer. The command prompts for the passwords and certificate details. Replace the example path; do not use an existing published app’s identity with a different signing key.

keytool -genkeypair -keystore YOUR_PRIVATE_PATH/upload-keystore.jks -storetype JKS -alias upload -keyalg RSA -keysize 2048 -validity 10000

Private signing file structure

Create android/key.properties using your own local values. The template below contains placeholders only. The source archive intentionally includes no signing credentials.

storePassword=YOUR_PRIVATE_STORE_PASSWORD
keyPassword=YOUR_PRIVATE_KEY_PASSWORD
keyAlias=YOUR_UPLOAD_KEY_ALIAS
storeFile=YOUR_ABSOLUTE_KEYSTORE_PATH

Connect your key to Gradle

In android/app/build.gradle.kts, add import java.util.Properties before the existing plugins block. After that plugins block, load your private file:

val merchantKey = Properties().apply {
    val configFile = rootProject.file("key.properties")
    if (configFile.exists()) {
        configFile.inputStream().use { load(it) }
    }
}

Inside the existing android { ... } block, add this signing configuration before buildTypes. The example deliberately fails when the signing file is incomplete, so a store release is not silently signed with a preview key.

signingConfigs {
    create("merchantRelease") {
        keyAlias = merchantKey.getProperty("keyAlias")
            ?: error("Missing upload key alias")
        keyPassword = merchantKey.getProperty("keyPassword")
            ?: error("Missing upload key password")
        storePassword = merchantKey.getProperty("storePassword")
            ?: error("Missing keystore password")
        storeFile = file(merchantKey.getProperty("storeFile")
            ?: error("Missing private keystore path"))
    }
}

Replace the existing release assignment signingConfigs.getByName("debug") with your new configuration. Keep one release block:

buildTypes {
    release {
        signingConfig = signingConfigs.getByName("merchantRelease")
    }
}

Keep key.properties and the keystore outside your distributed source. On Windows, use a correctly escaped path in the properties file; forward slashes in an absolute path can avoid backslash escaping. Validate signing with your platform tooling and internal test track.

Creating this file alone is insufficient: Gradle must load it and select the release signing configuration. Never publish your keystore or this file in support tickets. Review Flutter’s complete Android release instructions for the current tooling and platform steps.

13 / YOUR IOS DEBUT

Build & release iOS

Use a Mac with Xcode, CocoaPods and your Apple developer account. The iOS source is included in your Flutter download.

1. Prepare the project on macOS. Extract the Flutter source, run flutter pub get and resolve the relevant flutter doctor -v findings.
2. Open the workspace. Open ios/Runner.xcworkspace in Xcode after CocoaPods dependencies are installed. Use the workspace rather than the project file.
3. Set the identity and team. In Runner’s Signing & Capabilities, choose your Apple team and unique bundle identifier. Register that identity with your own Apple developer/App Store Connect account.
4. Apply branding. Change CFBundleDisplayName in ios/Runner/Info.plist and replace the AppIcon asset set. Check launch assets and supported device orientations.
5. Review payment return handling. Update the Stripe URL type if you rename the wooapp scheme. Verify PayPal approval and return behavior with the bundled bridge and your account configuration.
6. Build with the store URL. Use your real HTTPS store address. Resolve signing/provisioning errors in Xcode.
7. Test via TestFlight. Verify real-device checkout, approval/cancel flows, network interruptions, account recovery and accessibility. Check your own app’s privacy behavior.
8. Prepare App Store Connect. Complete listing assets, privacy disclosures, review notes/test accounts where applicable and the latest Apple requirements. Submit only after verification.

flutter pub get
cd ios
pod install
cd ..
open ios/Runner.xcworkspace
flutter build ipa --release --dart-define=STORE_URL=https://your-store.com

# Typical output folder: build/ios/ipa/

macOS commands above are for a Mac terminal. Keep Apple certificates, provisioning materials and account credentials private. Follow the official Flutter iOS release guide for current signing/export steps. Store acceptance and account approval are controlled by Apple, not guaranteed by the source package.

14 / READY MEANS TESTED

Your launch checklist

Use this checklist for each merchant release. Save your progress in this browser as you prepare your own store and app release.

15 / KEEP YOUR NEXT CHAPTER SMOOTH

Product updates

Keeping WooApp up to date

1. Back up WordPress files/database and keep your current working app source and signing materials.
2. Read the new release notes and verify the app/API compatibility requirements.
3. Upload the new installable plugin ZIP on staging. Confirm schema readiness and test your existing customer flows.
4. Merge new Flutter source changes with your own branding, app identity and customizations. Preserve private build settings outside the vendor archive.
5. Run analysis, tests and device/payment checks with the new version. Increment native build numbers before store upload.
6. Roll out the verified plugin/app pair in a planned sequence and monitor orders, server errors and provider events.

Keep your app identifiers and signing materials safe for future WooApp updates. Increment platform build numbers when publishing a new release to your distribution channels.

16 / FIND YOUR NEXT STEP

Troubleshooting

17 / A LITTLE CONTEXT GOES A LONG WAY

How everything connects

The customer app calls WooCommerce Store API for catalog/cart and /wp-json/wooapp/v1/ for WooApp configuration, accounts and checkout. Prices and order totals are calculated by the store. The app never needs an administrator session to fetch the catalog.

Customer sessions use bearer tokens. Native Android/iOS store session material in platform secure storage; browser preview keeps it in memory. Payment secrets remain on the server. Customer and payment responses should bypass shared page/CDN caching. Hosting must forward the required authorization and cart headers.

18 / YOUR WOOAPP REFERENCE

Features & compatibility

See Requirements & compatibility for the supported platform versions, product types and extension scope. Your developer configures app identifiers, signing and your canonical HTTPS store URL. Store content and branding are managed in WordPress.

19 / YOU DON’T HAVE TO FIGURE IT OUT ALONE

Getting support

Contact Tqniyati for purchase-related setup questions and reproducible product issues, within your purchase’s support terms. Keep your purchase details in the private support channel rather than public comments.

Include the details that help us help you

• Plugin/app version, WordPress/WooCommerce/PHP versions and Flutter version.
• The affected platform and whether this is a browser, debug or signed release build.
• The exact steps, expected result and actual result.
• A sanitized screenshot/error log and a reproducible product/order reference if applicable.
• Any custom checkout/product extensions and your hosting cache/security setup.

Do not include passwords, full payment details, private keys, customer tokens or signing files. For a required additional payment gateway, share its official developer documentation, country/currency and account requirements. Integration development is offered at no extra charge subject to technical feasibility and an agreed delivery schedule; provider fees remain yours.

Broader custom app design, bespoke features, store creation or publishing assistance can be discussed separately. App-store acceptance remains subject to the platform’s review.

20 / BUILT WITH GOOD FOUNDATIONS

Credits & licenses

WooApp is an independent product. Developed by Tqniyati. WordPress, WooCommerce, Flutter, Stripe and PayPal names are used to describe integrations and remain the property of their respective owners. Their appearance does not imply endorsement.

• Flutter/Dart and packages listed in the included pubspec.yaml and pubspec.lock. Preserve the notices generated/included by your dependencies.
• DM Sans and Cormorant Garamond: bundled under their included SIL Open Font License notices. DM Sans license · Cormorant license.
• Store photography and demo video: project-created sample assets used to illustrate the demonstration store. Customer apps retrieve their own store media rather than bundling this catalog.
• Guide screenshots: captured from the local WooApp staging installation. They illustrate the plugin controls and app journeys described in this handbook.

Your purchase license and the provider/platform terms govern use of the product and integrations. See the item’s current license information on CodeCanyon. This guide does not replace those terms.

Now, make it yours.

A little setup. A whole new way to shop.

Back to your first connection ↑