Thanks. Is it possible to get a login to https://barnetnetwork.com/ as well? I've answered a bunch of my own questions using the API key, and I can probably answer a few more with a login. But my main question still isn't answerable with what I have, so I'll lay it out as clearly as I can. It comes down to how we process payments, and there are three general possibilities. **1. There's a checkout-only handoff.** Customers browse products on our WordPress site, and when they check out we hand the cart to you to take payment. This is what we understood initially and what we quoted on. To be precise, I don't mean your full hosted storefront, which I understand you build for $1,500 plus hosting. I mean a handoff where the catalogue and product pages stay on our site and we pass a completed cart to you purely for payment. Does that exist as a product? I can't find anything in the API that would support it, so I suspect not, but I'd rather ask than assume. And if it does exist, is it on the Kort side or the Barnet side? **2. We process payments on the WordPress side using Kort.** Customers never leave our site at all, which is honestly a better experience than a handoff, so I'd argue the extra development cost is worth it. I'm assuming Kort is the processor here, since I can see PayHQ on your side and Keith already processes in-store with you. If that's the path, I need a few things: - **Client ID and Client Secret for PayHQ.** From your docs these are generated in the PayHQ dashboard under Settings > eCommerce. Since Keith already processes with Kort at the retail location, I'd guess he already has a PayHQ account and this is just a matter of enabling eCommerce on it. Can you confirm? If I can get a login I can likely pull the credentials myself. - **Does PayHQ offer a hosted payment page or drop-in card fields?** Your docs mention tokenization and a customer vault but don't say either way. This matters a lot for scope. If we can redirect customers to a Kort-hosted payment form and back, the build is much smaller and it keeps us in the lightest PCI tier. If we have to build the card handling ourselves, it's considerably more work. **3. We bring our own payment processor**, something like Stripe. I doubt this is what you'd want based on our conversations, but from what I can see in the API it does look technically possible, so I'm listing it for completeness. I'm still hoping for option 1, since that's what we scoped. Option 2 is very doable and is arguably the better outcome for Keith, but I can't find any existing WooCommerce plugin for PayHQ, which means building our own payment gateway. We can absolutely do that, it's just a non-trivial amount of work to add to the scope, so I need to know before I can price it properly. --- **One question that blocks us either way: is there a test or sandbox account on the Barnet side?** I can see PayHQ has a demo environment, with odd dollar amounts approving and even amounts declining, so testing payments is covered. But I don't see anything equivalent for Barnet. Without it, every test order we push during development creates a real order in Cork & Barrel's live POS, moves real inventory and shows up in real reporting. That isn't something we can work around by being careful, so if no sandbox exists we'll need to agree on an approach before we write any order-push code. --- A few other things I noticed while poking around. None of these are showstoppers, just worth being aware of. - **The full inventory is accessible through the API, which is great news.** I pulled all 2,706 web-enabled products in a single request in about 2.5 seconds, and 98.8% of them have a valid barcode, so Google Merchant Center should work well. - **Product data has some gaps.** 723 of the 2,706 products have no image, and 0 of 2,706 have a product description or brand name. Not a blocker, but it's meaningful for SEO and for Merchant Center optimization, and it's something Keith and I will need to work out. - **There doesn't appear to be any way to update an order after it's created.** I can see status values for cancelled and refunded, but no endpoint to actually set them. This only matters under option 2. If we're pushing orders into Barnet from WordPress, then a refund or cancellation would have to be handled manually in Barnet by staff, which leaves the two systems out of sync. Is there an endpoint for this that isn't in the docs? - **Small bug in the products endpoint.** Passing `show_on_web=false` returns the same 2,706 records as `show_on_web=true`, rather than the items not flagged for web. Looks like the parameter filters whenever it's present regardless of its value. Not affecting us, but you may want to know. - **Your wildcard certificate has expired.** The main barnetnetwork.com certificate is current and fine, but *.barnetnetwork.com expired back in March 2025. Doesn't affect us since we use the main hostname, just flagging it in case it's news. Thanks again.