не не, с этим все чисто. В тз упоминаеться Credit Cards, charges и тд

ок, спс

https://www.pcisecuritystandards.org/documents/pci_ssc_quick_guide.pdf 14-15 страницы

оооо, годнота. Спасибо большое!

обычно ты карту не хранишь, а хранишь ее токен, который тебе платежный оператор выдает.

Подрубаешь у себя Stripe (или аналог), пользователь когда заводит карту в твоем приложении, Stripe дает тебе токен. И потом ты отправляешь токен страйпу, чтобы они с этого юзера деньги списывали.

Токен этот дествует только для этой карты пользователя в связке с твоим приложением. Если токены утекут, то воспользоваться ими, чтобы списать бабла с пользователей на каком-то другом сайте / приложении не получится. Ну и действуют они только какое-то время, и их надо через страйп же ресетить.

АПИ у всех платежных операторов разное, но суть +- такая.

Да, все так.
Кстати, а у Страйпа и других как там в базе? Где-то же должны "родные" значения лежать.

а вот у них как раз карты и лежат. Потому что они проходят 7 кругов ада, чтобы от visa / mastercard разрешение получить хранить карты.

Раньше - лет 20-25 назад - получить разрешение было +- легко, и многие магазины карты хранили. Но со временем гайки закручиваются, и сегодня это сложная инженерная задача. Хранилища зашифрованы, постоянно перешифровываются, расписаны процедуры чтения / записи / доступа к данным и тд.

Ребят, в доке ноды представлена такая схема:
  ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
  └───────────────────────────┘
Содержимое очереди таймеров, исходя из неё, исполняется раньше, чем содержимое стадии пендинг коллбэков. Но в реальности же все колбэки таймеров исполняются после исполнения условных промисов. Можете объяснить это несоответствие?

Это таски event loop и у каждого своя приоритетность, которая не соответствует последовательности в которой она написана. Условно landing callback имеют более высокий приоритет нежели timers насколько я помню. Но и тут все не однозначно, если консолить setTimeout со вторым параметром 0 и любого промиса то, получится что иногда может быть первым timers нежели pending callback

Просто исходя из доки, каждая фаза имеет свою очередь, и следующая не начнётся, пока не очистится очередь текущей фазы...

Тут все верно сказал но думаю что все же у тасок своя приоритетность выполнения которую тоже стоит учитывать

Ну вот, значит сперва должны исполниться все коллбэки таймеров, а потом всё остальное.

Но такого не происходит.

Это если смотреть на таски последовательно

Но они не последовательные так как каждая имеет свой приоритет выполнения, и тот же callback выполниться первее нежели чем timers но встречаются случаи когда timers все же бывает раньше чем callback

Тут ещё зависит от времени выполнения самой функции, так как одна из этих тасок может попасть раньше другой в стек вызовов event loop

И из-за этого есть эта неопределенность

А как ты определил что не происходит?
Можешь код показать?
Тонкие места могут быть в том, что резолв промиса это микротаска, а у таймеров нет задержки 0, она всегда минимум 1

Тогда где место промисов в этой всей схеме.