Thanks for the detail — I dug into this and want to correct one thing before you spend more time on it.

There is no woo_wallet_idempotency table in 1.6.8 or any other version. Idempotency keys are stored as WordPress transients, not in a table, so a missing table isn’t the problem. TeraWallet only ever creates three tables: woo_wallet_transactions, woo_wallet_transaction_meta, and woo_wallet_referrals.
1.6.8 contained no database changes at all — it was a locale/translation fix release. The last version with a schema migration was 1.6.4, so there was no upgrade for 1.6.8 to run and nothing that reactivation would create.

Migrations aren’t tied to activation. The upgrade routine runs on every page load, comparing the woo_wallet_db_version option against the plugin version. You can confirm on the affected site with wp option get woo_wallet_db_version — it should match the installed plugin version. If it does, the upgrade path has run.

debit() returning false with no SQL error is expected behaviour, not a symptom of a missing table — a missing table would raise a $wpdb error. It returns false silently in five cases: no user ID, the wallet account is locked, the row lock timed out, the ledger balance is insufficient, or the insert failed. In practice, it’s almost always a locked account or insufficient balance. Worth checking:

is_wallet_account_locked( $user_id );                              // expect false
woo_wallet()->wallet->get_wallet_balance( $user_id, 'edit' );      // vs the debit amount

One caution if you use the credit-expiry add-on: the debit gate checks the raw ledger total, while the displayed balance is the filtered post-expiry figure. The two legitimately differ, so compare against the raw total when diagnosing.

That said, 1.6.8 does have a real bug that matches your symptoms — just a different one. Every REST API write endpoint (terawallet/v1/admin/transactions, transaction purge, transfers error) is affected because a required class was never loaded. If your integration creates debits over the REST API, that’s very likely what you hit, and a client that treats a 500 as a failed debit would report exactly what you’re seeing.

This is fixed in 1.6.9 and will be published at the end of this week, along with a related issue where retrying could report a completed transaction as failed — or, with sufficient balance, charge twice. I’d recommend updating rather than pursuing the table theory. If debits still fail after 1.6.9, send the output of the two calls above, and I’ll take another look.