Payment Methods

Manage your saved cards under Membership → Payment method.

Add a card

1. Go to Membership → Payment method.
2. Choose to add a card and enter your card details.
3. Save it to your account.

The card form matches whichever theme you're using — dark or light. See Appearance.

Manage cards

• Set a default — the default card is used for your subscription charges.
• Remove a card — delete a card you no longer use.

Payments are processed securely by Stripe. OneTake doesn't store your full card number.

If the payment form won't load

Occasionally the payment fields fail to load — for example, if an ad or privacy blocker stops Stripe's frames from loading, or there's a network hiccup. Instead of leaving the form stuck on a loading placeholder, OneTake shows a message:

"The payment form couldn't load. Refresh the page; if it keeps happening, turn off any ad or privacy blocker for this site, or contact support."

This applies both here, when adding a card, and on the payment and billing-address fields you fill in when subscribing to a plan from Membership → Plan. On the subscribe flow, the Subscribe button stays disabled while this message is showing.

If subscribing fails unexpectedly

When you select Subscribe (for a new card) or Confirm & Subscribe (for a saved card) and starting the subscription fails, OneTake shows whatever message the server sent back, when it has one.

When the server does send a usable message, it's shown as written — except for a server-side fault (an HTTP 500-and-up response), where OneTake appends a reference id in parentheses, for example:

"Stripe request failed. (reference sfo1::r-8)"

so you have something to quote to support. A failure the server can already explain on its own — for example, your account already has an active subscription, or your card was declined — doesn't get a reference added, since there's nothing extra to look up.

When the server's reply carries no usable message at all — for example, a server error with an empty or unreadable body — OneTake no longer tells you to try a different card. That used to be the fallback for every failure, including ones that had nothing to do with your card. Instead you see the HTTP status and, when available, a reference id you can quote to support:

"Subscription failed (HTTP 500). Please try again; if it keeps happening, contact support and quote <reference id>."

The reference id is omitted from the message when none is available. Either way, the failed response is logged on our side so the cause can be traced.

This also covers a case that previously escaped with no message at all: an unexpected server-side failure while starting your subscription — for example, an outage in a backend OneTake depends on. That now comes back as a proper error response reading:

"Something went wrong starting your subscription. Please try again."

with a reference id attached, rather than a blank failure the checkout page could only describe as a card problem.

A reliability fix: the anti-abuse check no longer blocks checkout during an outage

Starting a subscription, and adding or removing a payment method, are both protected by an anti-abuse limit — described in Plans → Changing or canceling — that caps how many times you can submit those forms in a short period. That limit depends on an internal service.

Previously, if that internal service was unreachable, every subscribe or payment-method request behind it failed outright — a different kind of outage could make checkout impossible, with no card actually at fault. That's been fixed: when the anti-abuse check itself can't be reached, OneTake now lets your request through rather than blocking it, the same way it would if the check had simply passed. The ordinary case — you actually hit the limit by retrying rapidly — is unaffected, and still shows the normal "too many requests" message asking you to wait.

A reliability fix: a declined card or abandoned checkout no longer blocks your next attempt

When a subscribe attempt doesn't go through — your card is declined, a 3-D Secure check fails, or you close the tab partway through checkout — Stripe is left holding an unfinished subscription for that attempt behind the scenes, until it automatically expires it roughly a day later.

Previously, trying to subscribe again while that leftover attempt was still around could fail with the same message used for a genuine active subscription:

"This account already has an active subscription. Cancel the current plan from /membership/plan before subscribing again."

— even though nothing had actually gone through and there was no real plan to cancel.

That's fixed. Before starting a new attempt, OneTake now automatically clears away any abandoned, never-paid attempt left over from before, so retrying after a declined card or an interrupted checkout just works.

This only touches attempts that never charged you. If you genuinely already have an active subscription, trying to subscribe again still correctly refuses with the same message, and you'll still need to cancel your current plan from Membership → Plan first.

In the rare case where the leftover attempt can't be cleared, your retry fails with an error instead of risking a duplicate subscription — wait a moment and try again.

A reliability fix: your plan now activates correctly even when Stripe's events arrive out of order

Right after you subscribe, Stripe sends OneTake a quick sequence of events about your new subscription: one confirming the subscription was created (while your card is still clearing), and — moments later, often within the very same second — one confirming it's active and your plan should take effect. Stripe doesn't guarantee these arrive in order, and with only one-second precision on their timestamps, OneTake couldn't always tell which one actually happened first.

In a rare timing case, this could cause the activating event to be mistaken for old news and skipped — leaving your account showing your previous plan even though you'd already been charged for the new one. That's fixed: for these two events, OneTake no longer relies solely on the event's own snapshot of your subscription. It checks your subscription's current status with Stripe directly, so the same, correct, fully-active plan is recorded no matter which of the two events happens to be processed first.

This doesn't change how cancellations are handled — a cancellation event still reliably revokes your plan, even if it lands in the same instant as one of these events. See If your subscription or trial lapses.

While your new plan finishes activating

Right after a successful subscribe, the confirmation page may briefly show:

"Finishing setup. Your account unlocks as soon as the payment confirms."

Your new plan reaches OneTake a moment after Stripe confirms your payment, through a background update, so there's a short gap between finishing checkout and OneTake fully recognizing your plan. While that note is showing, the page automatically checks again every couple of seconds. Once OneTake sees your new plan, the note disappears and the rest of the app — including any "trial expired" or "subscription ended" banner — updates to match, without you needing to reload the page yourself.

If OneTake still hasn't picked up your new plan after about 30 seconds, the note changes to:

"Your payment went through, but your account hasn't picked up the new plan yet. Reload this page in a minute; if it still shows an expired plan, contact support."