Pay-as-you-go

Pay-as-you-go, or PAYG, lets you buy proxy resources as you need them, without committing to the same package every month. You might purchase traffic for a short project, add more when a job grows, and leave the remaining allowance for later. Its main advantage is control over when you buy. Whether you can keep the unused resource indefinitely depends on the plan.

Within proxy pricing models, PAYG describes the purchasing arrangement. Per-GB and per-request pricing describe the unit being sold. A service can be both PAYG and priced per gigabyte. The important questions are how much you must pay upfront, what that payment buys, what can expire, and what authorizes another charge.

How a PAYG purchase works

Consider an illustrative offer: 10 GB for 40 USD, purchased once, without monthly renewal. You pay 40 USD and receive access to the proxy network with a 10 GB allowance. Your software then uses 2 GB to collect product prices. You have 8 GB left for subsequent work, subject to the plan's validity and account rules.

The used traffic is worth 8 USD at the package rate, but 40 USD has already left your payment account. The remaining 8 GB is a service allowance, not automatically 32 USD that you can withdraw. The amount paid, the amount consumed, and the amount still available are three different figures.

Some services add a wallet between payment and usage. You first deposit money, then use that balance to purchase traffic or cover metered charges. Funding the wallet does not necessarily activate a product. Check whether the dashboard shows money, GB, request credits, or several separate balances.

What can be sold through PAYG

Residential and mobile pools can be sold per GB, but datacenter proxies can use this model too. A provider may sell one network type through PAYG and another only through a subscription. A one-day proxy rental also runs on a timer: leaving it idle does not preserve that day for later.

Prepayment is a normal PAYG arrangement. Payment after usage, through an invoice or credit agreement, is another arrangement that must be explicitly offered. PAYG does not promise that the provider will let you use its network before paying.

The minimum payment matters as much as the unit price

A low price per GB can conceal a larger entry payment. In an illustrative offer priced at 1 USD/GB with a 50 USD minimum purchase, a 3 GB job consumes 3 USD of resource but requires 50 USD upfront. The remaining resource may still be useful, yet the immediate cash requirement is much higher than the job's consumption.

Check the minimum for both the first purchase and later top-ups. Some services offer a small introductory order and require substantially larger subsequent payments. A 5 USD introductory purchase followed by a 50 USD minimum for the same proxy type is a real example of this arrangement.

PAYG can also offer volume discounts. The lower rate may require buying a large block at once; it need not apply retrospectively when many small purchases eventually reach the same total. Compare the full payment, the validity of the resource, and the quantity you can realistically use.

An advertised “from” price may belong to a monthly commitment, a different pool, or a much larger order. It is not a reliable PAYG budget until you select the actual purchase mode. A higher price alone does not establish better IP reputation or better results on your targets.

When unused traffic and wallet funds expire

“No subscription” and “no expiration” are separate promises. Check all of the following:

• Traffic validity: whether purchased GB last indefinitely or expire after a fixed period. A 12-month validity period is one documented arrangement.
• Wallet validity: whether unused monetary credits have their own deadline.
• Inactivity: whether preserving the resource requires actual usage, another top-up, or an active account arrangement. Some terms allow unused PAYG resources to expire after more than three months without use.
• Plan changes: whether switching to a subscription ends the validity of the old PAYG allowance.

If the terms require usage, simply logging into the dashboard may not satisfy them. Establish what counts as activity and whether a new purchase extends all remaining traffic or only the new batch.

Bonus credits can have a shorter life and different product eligibility than purchased funds. Check which balance is spent first. A large combined number in the dashboard does not mean that every part of it has the same value or deadline.

Automatic purchases can happen without a subscription

Three separate mechanisms can create charges:

A PAYG account can use the first two without having a monthly subscription. Turning off one does not necessarily disable the other.

Some systems buy traffic in 1 GB blocks when the current allowance reaches 90% usage. With an illustrative price of 4 USD/GB, the first purchase costs 4 USD. Once 0.9 GB has been used and the next purchase triggers, another 4 USD is spent. You have bought 2 GB, used 0.9 GB, and have 1.1 GB remaining. Consumption is gradual; purchasing happens in blocks.

Other systems let you choose the threshold and quantity, such as buying 5 GB when less than 1 GB remains. That protects continuity, but the threshold does not cap the total number of future purchases. Check the funding source, purchase size, and any overall spending ceiling before leaving a job unattended.

A spending alert is not a spending cap

Find out what the configured limit actually does. An email notification can leave requests running. A traffic limit may apply to one proxy user, while other users continue consuming the shared balance. Disabling auto-recharge prevents further funding but can leave existing funds available for use.

Even a limit configured to suspend service may be checked periodically. A documented implementation checks zone limits every 15 minutes. At a steady consumption cost of 18 USD per hour, another 4.50 USD corresponds to 15 minutes of work. This is an illustration of delayed enforcement, not a guaranteed overrun.

Combine provider controls with a task budget: a maximum number of operations, bounded retries, a deadline, and a way to stop the process. Leave room for reporting delays and requests already in progress. Separate credentials or subusers, where available, make it easier to identify and limit one project's consumption.

What counts as paid usage

For a raw proxy billed per GB, the meter may include uploaded requests as well as downloaded responses, headers, cookies, and TLS traffic passing through the tunnel. A saved HTML file is only one part of that exchange.

A response containing a CAPTCHA, a block page, or an error may consume traffic even though it produces no usable data. Provider-generated connection failures and errors returned by the target site can have different billing treatment. Read the error origin and product rules; do not assume that every 403 or 502 has the same financial meaning.

With a scraping API, the unit may instead be a successful request or returned result. Check its definition of success. HTTP 200 alone does not tell your business whether the required record was retrieved. Configuration can also matter: some APIs switch from charging successful attempts to charging all attempts when custom headers or cookies are enabled.

Purchase blocks and minimum billing increments

Buying a whole GB does not mean every small request costs a GB. Three different forms of granularity need separating:

• the smallest resource package you can purchase;
• the minimum amount billed per request or session;
• the precision used to display a counter.

A published datacenter product specifies a 512-byte minimum per request. That is a concrete example of a minimum charge, not evidence that proxy services generally round every request up to 1 MB. Ask which event triggers rounding and whether it is a minimum charge or rounding to successive increments. A dashboard displaying only two decimal places does not by itself prove that billing uses the same precision.

How an unattended job spends the balance

Suppose software makes 500 requests per minute, averaging 200 KB of billed traffic per request in both directions combined. At an illustrative rate of 3 USD/GB, using decimal units where 1 GB = 1,000,000 KB:

These figures assume a steady rate and no additional minimum charges. If half the attempts stop producing useful results, the resource bill does not automatically halve. The cost per useful result rises, and auto top-up can keep financing the failing job.

Monitor completed work alongside traffic. A scraper that uses fewer GB but misses half the required records has not necessarily become cheaper. Calculate total usage cost divided by the number of usable results, with the same definition of a result throughout the test.

When PAYG is cheaper than a subscription

Compare an illustrative PAYG rate of 4 USD/GB with a subscription costing 60 USD for 20 GB each month, without rollover. Assume equivalent features, no additional minimum payment, and the same tax treatment.

The subscription advertises an average rate of 3 USD/GB, yet using only 8 GB makes its effective cost 7.50 USD per used GB. PAYG costs more per purchased unit and less for that month's completed workload.

Within the package allowance, the break-even point is monthly subscription price divided by the PAYG rate: 60 ÷ 4 = 15 GB. Above the included allowance, add the subscription's extra-traffic rate. Rollover, promotional pricing, different features, and minimum deposits can change the result.

For three months using 2, 18, and 0 GB, PAYG costs 80 USD in this example, versus 180 USD for a continuously active subscription. Using PAYG in the quiet month and a subscription only during the busy month would cost 68 USD, if switching is allowed without additional costs or loss of useful resources. Check that condition before treating it as a purchasing strategy.

PAYG is useful for pilots, irregular monitoring, seasonal work, uncertain volumes, and a secondary provider. Stable, sustained consumption can make a subscription or negotiated commitment more economical. A dormant backup account still needs attention to expiry, credentials, and access rules.

Reduce traffic without breaking the task

Download the data you need

If an authorized HTML or JSON endpoint supplies the required information, an HTTP client can avoid loading a complete browser page. Use a browser when the task needs its rendering, state, or interaction. Compare complete results rather than one small API response with an unrelated full-page operation.

In browser automation, prevent unnecessary images, media, fonts, and selected analytics requests from being sent. Test the page afterward: disabling required scripts or styles can break extraction and trigger more reloads. Resource blocking should reduce the cost of successful work, not just the size of an incomplete page.

Reuse resources and connections

Reuse suitable client sessions and connections instead of establishing a new connection for every request. HTTP clients with connection pools support this directly. Merely adding a Connection: keep-alive header does not guarantee reuse if your code recreates the client each time or closes the response incorrectly.

Cache reusable resources only while they remain valid, and keep account-specific data separate. Check the automation framework's behavior: enabling request routing in Playwright disables its HTTP cache. Combining a blocking rule with an assumed cache saving can therefore produce a different result from the one you expected.

Bound retries and redirects

Set an attempt limit and a time limit for each operation. For example, three total attempts means the original attempt plus at most two retries. Use pauses between attempts and stop a batch when repeated failures show that its configuration or target access needs attention.

Do not respond to every error by blindly rotating the IP. Incorrect credentials, exhausted funds, disallowed targets, and provider restrictions require different fixes. Check status and headers early where your client permits it, but remember that CAPTCHA pages can return HTTP 200 and may require content inspection. Aborting a response cannot undo bytes already transferred.

Use supported compression

Let the client negotiate compression that it can actually decode. Do not advertise Brotli support merely by adding br if the client lacks a decoder. The server must also support and choose compression.

The transferred representation can be much smaller than the decompressed document saved locally. That can reduce a byte-based bill, but it does not necessarily reduce a per-request API charge. Measure the saving on the actual product instead of assuming a fixed percentage.

Keep DNS choices separate from bandwidth promises

Choose local or proxy-side name resolution according to the application and privacy requirements. SOCKS5 does not automatically make a job cheaper than HTTP proxying. DNS configuration should not be sold as a universal PAYG saving, and switching protocols does not remove the bytes your task still needs to transfer.

How to investigate a counter that looks wrong

A mismatch deserves investigation. It is not, by itself, proof that the provider inflated your bill. Your program may count decompressed bodies while the provider counts transferred bytes, or omit uploads, browser resources, redirects, failed attempts, and other users sharing the account.

Run an isolated comparison:

1. Use a separate credential or subuser if available, and stop unrelated traffic.
2. Record the starting balance, time zone, billing unit, and current rate.
3. Run a small, repeatable set of permitted requests. Record attempts, useful results, and uploaded and downloaded data.
4. Stop the job and wait for the documented statistics update before reading the final counter.
5. Compare usage and purchase records separately. An automatic package purchase can explain a payment jump without any unexplained traffic.

If the difference remains, send support the interval, product, request identifiers where available, and measured totals. Ask what was counted and whether minimum billing increments apply. Keep credentials and sensitive payloads out of shared logs. Pause larger purchases until a material discrepancy is explained.

Check service quality separately from billing accuracy. Unexpected locations, poor success rates, or a network that does not match the purchased product can make cheap traffic expensive. An IP database label alone is not enough to prove deliberate substitution; document the mismatch and ask for its explanation.

Running out of funds and changing plans

When prepaid resource runs out, new requests may stop until a purchase succeeds. Auto-recharge can fail because of insufficient funds, a declined payment, or required verification. Confirm both the payment and the available product allowance before restarting a job. A successful deposit does not guarantee that an interrupted session or the same exit IP will return.

Moving to a subscription may also affect unused PAYG traffic. Some systems do not allow the two modes to coexist for the same product. Check whether the old allowance transfers, expires, or remains separate, and which allowance is consumed first.

If the wallet holds money rather than GB, a changed rate changes its purchasing power unless your agreement preserves the earlier rate. Illustratively, 30 USD buys 10 GB at 3 USD/GB or 7.5 GB at 4 USD/GB. Check the rate for the next automatic purchase and whether a promotion applies only to the first order.

Stopping usage, disabling future purchases, and requesting a refund are separate actions. Some PAYG products exclude unused purchases from their standard refund offer. A credit returned to the dashboard is not the same as money returned to your payment method. Read the conditions for the specific top-up, including bonuses, rather than assuming that a subscription refund promise covers it.

What to verify before your first purchase

Before funding the account, establish:

1. The resource and features: network type, locations, session behavior, concurrency, target restrictions, and any separately priced options.
2. Today's full payment: minimum order, applicable taxes, currency conversion, and whether the small introductory offer can be repeated.
3. The counters: money, GB, requests, minimum billing increments, and which failures are charged.
4. The validity rules: resource expiry, wallet expiry, inactivity, and bonus conditions.
5. The next charge: auto-recharge threshold, purchase size, payment source, and how to disable it.
6. The stop conditions: whether limits alert or suspend, what they cover, and how quickly they take effect.
7. The exit route: treatment of unused resource when changing plans, closing the account, or requesting a refund.

Start with a small representative job that the available purchase minimum allows. Measure its useful output and total consumption before funding a larger run. PAYG gives you flexibility over purchasing; keeping it economical depends on matching those purchases to productive work.