WapifyDocs

InstaPay deposit

Ask Egyptian COD customers to transfer part of the order up front, and settle it against the screenshot they send back.

How much to ask for
Percentage of orderFixed amount
Deposit percentage
20 %
🧮 On a 1,250.00 EGP order, the customer is asked for 250.00 EGP.

A deposit is what turns a confirmed COD order into a committed one. The screenshot is the receipt — nothing on Wapify's side can see an InstaPay transfer.

FreeGrowthProEgypt only. Not included on Basic. Counts against your order-update allowance.

Cash on delivery is placed with nothing at stake, which is exactly why so much of it is refused at the door. Asking for part of the money up front changes that: a customer who has transferred a deposit turns up for their parcel. This automation asks for it on WhatsApp the moment they confirm, and gives you a one-click way to settle it when the money lands.

Egypt only

InstaPay is an Egyptian Central Bank scheme with no meaning anywhere else, so for stores outside Egypt this automation isn't shown at all — not locked, not greyed out, simply absent from the Automations page, the Orders menu and the Inbox template picker.

Eligibility comes from your Shopify store's own billing country. A brand-new Egyptian store whose details haven't finished syncing counts too, as long as it bills in EGP.

What fires it

The customer's own Confirm tap on the COD confirmation — not the order, and not the confirmation message being sent.

That ordering is the whole point. Asking somebody to wire money before they've said they want the order is how a store gets reported; asking straight after they've said yes is the natural next sentence in the same conversation.

It follows that with COD Confirmation switched off, nothing fires on its own — there's no Confirm tap to chain from. The card says so with a link to turn it on. You can still ask for deposits by hand from the Orders page or the Inbox.

Who gets asked

A deposit is friction you spend on purpose. Asking every confirmed customer for one costs you conversions on the orders that were never going to be refused, so you can point it at the orders that actually carry the risk.

Every confirmed COD order
Only certain governorates
Only certain shipping zones
Only customers with a risky history

One rule, not four filters. A customer asked for money up front may well ask why — you should be able to answer with a single reason.

Every confirmed COD orderThe default. Anyone who taps Confirm is asked.
Only certain governoratesPick the regions worth insuring — usually the ones your courier fails in most, or the ones that cost you most to reach twice. Matched against the delivery address on the order.
Only certain shipping zonesThe zones from your own Shopify delivery profiles — Upper Egypt, Remote areas. Faster than ticking governorates one by one, and it follows the zone: add a governorate to it in Shopify and this rule covers it from the next message, with no need to come back here.
Only customers with a risky historyRead per customer at the moment they confirm. Two signals, either or both: they refused a delivery from you before, or their acceptance rate is low — the same score the COD confirmation can note on an order.

The options are exclusive, and the lists come from your own delivery profiles rather than a built-in list of governorates. Your store has already decided which regions are expensive and awkward to reach, and that decision is exactly the judgement this needs; a governorate you don't ship to has no orders to target anyway.

A customer with no delivery history is not treated as risky. A first-time buyer is asked for nothing — the whole point of the risky option is that the evidence already exists.

Skip orders under

A minimum order value, applied on top of whichever option you picked. On a cheap order the deposit is more trouble than the order is worth. Leave it empty to ask on any order.

What it doesn't touch

  • Deposits you ask for by hand — from the Orders page or the Inbox — ignore all of this. Asking one specific customer is your call, not the rule's.
  • Orders the rule declines aren't logged. A narrowly-targeted store declines most of its orders by design, and a row for each of them would bury the sends that actually happened.
  • Nothing changes for stores that never open the card. The default is every confirmed COD order, which is exactly what the automation did before targeting existed.

An option that selects nothing — governorates with none ticked, the risky option with neither signal — sends nothing at all, and the card says so with a warning rather than letting you believe it's running.

The message's button opens your InstaPay payment link straight in the customer's InstaPay app. Copy it from InstaPay → Request money → share your payment link; it looks like https://ipn.eg/S/yourname/instapay/….

It has to be a real link. An IPA handle like someone@instapay isn't something a button can open, so Wapify only accepts a full https:// address.

No link, no sends. Until you paste one, deposit requests are skipped rather than sent with a button that leads nowhere — and the card warns you before you ever switch it on.

How much to ask for

Percentage of orderScales with the order — 20% of a 1,250 EGP order is 250 EGP. Rounded to the nearest 100, because a deposit is money a person hands over and "353.00 EGP" reads as a computation rather than a price.
Fixed amountThe same figure on every order, whatever it's worth. Never rounded — it's the number you typed.

Two floors keep the rounding honest: a deposit never rounds down to nothing, and it never exceeds the order total. A 100% deposit on a cheap order asks for the order's price, not more.

The settings card computes a sample as you type — "On a 1,250.00 EGP order, the customer is asked for 250.00 EGP" — using the same calculator the send uses, so the figure on screen is the figure your customers get.

What the customer gets

  • The deposit amount, in bold, inside a message that names their order.
  • A Pay with InstaPay button that opens your payment link.
  • An explicit request for a screenshot of the transfer.
  • A footer promising the order is reserved once you confirm the deposit.

The screenshot request is load-bearing, not politeness. InstaPay transfers land in your own bank account — there's no webhook, no gateway transaction, nothing Shopify or Wapify can observe. The screenshot is the only evidence this app ever sees, which is why the message asks for it in so many words.

Confirming a deposit

This is the one place in Wapify where a payment is recorded, and it's deliberately manual.

  1. The customer sends the screenshot

    A photo from someone who owes a deposit raises a Deposit check badge on their chat in the Inbox — the only badge that's a job rather than a description, which is why it sorts first.

  2. You look at it

    Then hit Mark as deposited on the order card in the customer panel.

  3. You type what actually arrived

    The panel does the arithmetic live — how much is discountable, what balance the courier will be left to collect — before you commit. Partial and renegotiated transfers are routine, so the amount you type wins over the amount that was asked for.

  4. Wapify makes it real in four places

    The order is discounted by that amount, the Waiting Deposit tag is swapped for Deposit Paid, a dated note records what was asked and what arrived, and the customer gets a WhatsApp acknowledgement naming the balance still due on delivery.

The badge clears itself once you've settled the deposit — the screenshot has been looked at, which was the badge's whole job.

The order is discounted, not marked partly paid. Shopify can only discount line items that haven't shipped yet, so if an order is already fulfilled the edit may be refused. The deposit is still recorded — the money did arrive — and the card tells you plainly that the total wasn't adjusted so you can collect the balance manually.

Order tags

⏳ Waiting DepositAdded when the request goes out. Readable at a glance in Shopify's Orders list, so nothing ships before the money is in.
💰 Deposit PaidReplaces it when you mark the deposit received. Swapped rather than stacked — an order still reading "waiting" after the transfer arrived is the tag that gets acted on.

Asking again

Re-sending a request updates the existing deposit rather than opening a second one, and it never resets a deposit you've already settled. Asking again after the money arrived is almost always a mis-click, and quietly flipping a settled order back to "waiting" would put the wrong tag on it and the wrong balance in front of the courier.

Sending one by hand

  • From Shopify's Orders page — select orders, open the menu and choose Ask for InstaPay deposit. See Actions on the Orders page.
  • From a chat — the Inbox composer's template picker lists it under Order updates, filled from the customer's most recent order. It sends even while the automation is off, which is what a store running COD confirmations by hand needs.

Both routes send the same approved template, because the wording is deliberately trigger-neutral: it never claims the customer just confirmed anything, so it reads correctly whether it follows a Confirm tap or you fire it a week later.

Neither route is filtered by Who gets asked. A rule decides who gets asked automatically; you deciding to ask one customer overrules it, which is the point of asking by hand.

Where the results show up

  • Logs → InstaPay deposit — every request, with its delivery status and failure reason.
  • Analytics → InstaPay deposit — requests sent, delivery rate and replies.
  • Inbox → Deposit check — the chats waiting on you to confirm a transfer.
  • Shopify — the tags, the discount and the note live on the order itself, so it carries its own audit trail even for someone who never opens this app.