Cloaking

What it changes

The cardholder statement stops carrying your store and starts carrying the platform:

• Receipts and 3D Secure pages name VinGate, not your store.
• Stripe's underwriting and risk see a single established platform account.
• Repeated buyer questions and bank blocks on an unfamiliar descriptor stop.

Who sees what

Two audiences matter and only one of them can be hidden. A cloaked charge is a Stripe destination charge, so Stripe always knows the destination account, its owners and its verification — cloaking is not hiding from Stripe. It is hiding from the buyer's bank and the card networks. Here is what actually happens to each field:

Five of those are yours to control, and all five are below: the description the payment carries, the tail on the statement, the site and category on the account, whether checkout runs on your domain or a host in the front site's, and whether the order still names products. The category on the statement is not yours — the platform's own Stripe profile sets it, which is the point: the bank authorizes against a software merchant either way.

The description is the one field worth a decision rather than a default. It reaches Stripe's dashboard, its receipt and its risk scoring, so a product name in it (“BPC-157 10mg x2”) quietly labels the category again. Settings › Cloaking offers three answers: keep whatever the checkout says, replace it with the brand name, or replace it with one flat line. Replacing it also collapses the order to a single line, because the line items are the same leak one level down. The bank never sees any of it, so this is about how much the processor gets told, not how the charge looks.

What it does not change

• The money path. Funds still settle to your connected account and are paid out by your bank on your normal schedule. VinGate never holds your balance.
• Your storefront. Same hosted page, same API, same branding, same webhooks.
• What you sell. Only who the statement names changes; nothing about your product or checkout does.

What you give up: on a cloaked charge VinGate is the merchant of record. The platform is debited for the chargeback, and the descriptor is only as trustworthy as VinGate's own account. The money is still yours to lose — the transfer is clawed back.

How it works

The charge becomes a Stripe destination charge: taken on VinGate's platform account, with the remainder transferred to your connected account in the same API call.

POST /v1/payment_intents            (platform key, no Stripe-Account header)
  amount                      = the order total
  transfer_data[destination]  = acct_your_connected_account
  application_fee_amount      = VinGate's cut
  statement_descriptor_suffix = your brand tail    -> prints "<PREFIX>* <TAIL>"
  # <PREFIX> is the platform account's own descriptor, not the business's
  # no on_behalf_of

Leaving on_behalf_of out is the whole trick. Sending it would settle the charge on your account, and Stripe would then print your descriptor — the uncloaked result.

A PaymentMethod belongs to whichever account created it, so the card is tokenized on the platform rather than your account, and the pin is remembered on the checkout so the capture, 3D Secure, void and refund all happen on the same side as the charge.

Requirements

• A connected Stripe account that Stripe has finished verifying. Its transfers capability must be active: that is what lets it receive a transfer, and it only activates once onboarding is complete.
• The same currency. Your account's default currency has to match the currency you charge in.
• Premium. Stripe routing is Premium, and cloaking is Stripe-only.

Cloaking is per business, not per account: two stores on one login can differ, and a business can be uncloaked again without touching the other.

Nothing here yet? The setup guide takes an empty account all the way to a payment first.

Turn it on

1. Pair the front site from the store's plugin (WooCommerce, Settings, Payments, VinGate, Front site): the other site runs this plugin, you approve from its own admin, and its name and address become the business's. That is the address Stripe opens when it looks at a payment, and an account keeps the one it was created with, so it has to happen before the next step. Typing the address into Settings › Cloaking instead works, but proves nothing about owning it.
2. Optional, Settings › Cloaking: pick the category Stripe files the business under, or leave it blank to be asked during onboarding. Also frozen at creation.
3. Optional, Settings › Checkout domain: the pairing proposes checkout. on the front host and attaches it; you only add the CNAME. The browser reports the page URL to Stripe when the card is tokenized, so a verified domain there beats the VinGate pay host; until it verifies, checkouts use that host instead.
4. Gateways: connect a Stripe account and finish its onboarding until it can charge (how that goes). Cloaking with no paired front site is refused here rather than minting an account that says peptides forever.
5. Settings › Statement descriptor: set the tail the buyer sees after VinGate's prefix — up to 15 characters when cloaked. Brand name, not product description.
6. Settings › Cloaking: tick “Charge through VinGate instead of this business”, and choose what the payment description says — the full description, your brand only, or one generic line. The bank never sees it, but Stripe's receipt and risk scoring do, and stores habitually write product names there. Save. It applies to the next checkout; nothing already taken is rewritten.

Business name rather than a product line matters here: the tail is all a buyer's bank shows them of you, and an unrecognised tail is what makes them call it fraud.

Check that it worked

Make one small live charge from a real card, then read the PaymentIntent back on the platform:

status                          = succeeded
application_fee_amount          = VinGate's cut (never 0)
transfer_data.destination       = acct_your_account
on_behalf_of                    = null
balance_transaction.account     = null            # the charge is on the platform
calculated_statement_descriptor = "<PREFIX>* YOURTAIL"

# and, separately, that the money moved:
GET /v1/transfers/<id>          -> destination = acct_your_account

Then refund it. You should see reverse_transfer: true: the clawback is the proof the transfer existed and that the platform is not quietly funding your refunds.

When it falls back

A checkout that was asked to be cloaked but cannot be still sells. It falls back to a normal direct charge — your own descriptor — instead of refusing the buyer, in three cases:

• no connected account has transfers active yet (mid-onboarding);
• the account's currency does not match the order;
• every cloaked account is at its volume limit for the day.

The pin records which way a checkout went, so a page that has already loaded the card form never switches processor mid-fill.

Refunds and chargebacks

Both reverse the transfer, so your share comes back off your balance and VinGate is not left paying for a sale that was undone. If your balance has not settled yet and cannot fund the reversal, VinGate funds the refund so the buyer is not blocked, and the reversal stays owed.

Partial refunds reverse proportionally. A chargeback also costs Stripe's dispute fee, billed to the platform — one more reason a cloaked account is only worth it for a business that keeps its side clean.

Limits

• A Square charge is never cloaked. Square has no destination charges, so a payment that lands there is the seller's own and the receipt shows the seller. The description policy still applies — the order collapses to one brand line and the note says the brand — and the statement line is whatever the Square account was configured with. To cloak a Square payment properly you need a Square seller belonging to the front entity; to cloak one without that, use Stripe.
• The prefix is VinGate's. It is the statement descriptor on the platform's own Stripe account — the company name on the account — not something a business can type.
• Stripe is never fooled. The destination account is right there on the payment, with its owners and its category. Cloaking changes the statement, not the facts, which is why a category a processor dislikes can still surface later.
• The store address stays on the account. Underwriting reads the account's business URL and category, and on a peptide store those still say peptides unless you replace them. Setting the front site and a bland category, and choosing a generic description, is as far as this goes: the money still lands on a peptide business, and a human reviewer who opens the front site can find the catalogue.
• The address bar costs the front site a record. Cloaked checkouts move to checkout.<front host>, which you point at us with one CNAME. Stripe learns the hostname when the card is tokenized, so leaving the record unpointed leaves your own domain in the address bar instead. A merchant who points their own domain at us keeps it for everything except cloaked checkouts.
• 15 characters of brand. The statement line is 22 characters and the prefix takes the front, so the tail is truncated to what fits rather than cut mid-word by Stripe.
• Cloaking is not category approval. It changes who the statement names, not what the processor knows. A business that breaks the rules still gets a cloaked chargeback.

Questions

Does it work with Square?

Partly, and only by hand. Square has no destination charges, so a Square charge is the seller's own and the receipt names the seller. The description policy and the brand statement line still apply, and they are what most of the effect is; the account itself has to be a Square seller of the front entity for the rest. If the payment lands on Square while the front brand is what the buyer was shown, the checkout page wears the front site's name and logo either way.

Does the buyer see VinGate?

On the statement and the receipt, yes. On the checkout page, no — that stays your brand.

Does it cost more?

Yes. VinGate pays the processor on a cloaked charge, so the per-payment fee there is the plan rate plus 2.90% + 0.30 rather than the plan rate alone: 6% (base), 3% (premium) becomes 8.90%, 5.90%. It is charged only on cloaked payments.

Can I turn it off again?

Yes, immediately, per business. Checkouts already in flight keep the shape they were pinned with.

Do refunds and payouts still work the same?

Refunds yes, from the same payment. Payouts are your bank's schedule on your own account, unchanged.