Разработчик

Ключове за плащане и ключове на касиер

Cardflo използва ключове за плащане и ключове на касиер, за да предостави сигурни и гъвкави опции за интеграция за търговците.

Ключовете за плащане управляват инициирането на платежната сесия и събирането на данни за клиенти, докато ключовете на касиер улесняват обработката на транзакции от страна на сървъра. Това разделение осигурява съответствие с PCI и стабилна сигурност за всички платежни потоци.

Категория
Разработчик
Възможности
10
Налично на
Всички планове
Кандидатствайте сега

Общ преглед

Разделянето на идентификационните данни на ключове за плащане и ключове на касиер представлява основна архитектура за сигурност в съвременната платежна оркестрация.

Ключовете за плащане са публично достъпни идентификатори, използвани в клиентски среди, като уеб браузъри или мобилни приложения, за иницииране на платежни компоненти и събиране на чувствителни данни на картодържателя. Тези ключове позволяват на търговеца да изобрази интерфейс за плащане, без да излага чувствителни бекенд разрешения.

Обратно, ключовете на касиер са ограничени, сървърни идентификационни данни, предназначени за удостоверена комуникация между сървър на търговец и платежния шлюз.

Чрез разделянето на тези роли, системата гарантира, че компрометирането на кода от страна на клиента не дава на нападател възможност да извършва административни действия, като иницииране на възстановявания на суми или прихващане на оторизирани плащания.

Този архитектурен подход помага за поддържане на съответствие с PCI DSS, като минимизира обхвата на системите, които взаимодействат директно с необработени платежни идентификационни данни, като същевременно позволява програмируем, гранулиран контрол върху жизнените цикли на транзакциите.

Как работи

  1. Иницииране на сесия от страна на клиента

    Интеграцията започва с използването на ключа за плащане във фронтенд приложението за заявка на сигурна сесия.

    Този ключ идентифицира самоличността на търговеца (MID) и разрешава изобразяването на сигурни платежни елементи, като гарантира, че данните за картата на клиента се токенизират, преди да достигнат до инфраструктурата на търговеца.

  2. Сигурно токенизиране на данни

    Докато клиентът въвежда своите данни за плащане, ключът за плащане улеснява директна връзка с хранилището. Чувствителни полета като PAN и CVV се преобразуват във временни токени.

    Този процес гарантира, че средата на търговеца остава извън основния обхват на изискванията на PCI DSS.

  3. Удостоверяване от сървър до сървър

    След като се генерира токен, сървърът на търговеца използва своя ключ на касиер, за да поиска официално разрешение от придобиващия. Този частен ключ потвърждава, че заявката е легитимна и позволява на шлюза да съпостави временния токен обратно със съхранените данни за плащане за обработка.

  4. Управление на жизнения цикъл на транзакцията

    Действията след оторизация, включително прихващане, уреждане и възстановяване на суми, се обработват изключително чрез ключа на касиер.

    Тъй като тези действия включват движение на средства, те изискват по-високо ниво на удостоверяване и ограничен достъп, които ключът на касиер от страна на сървъра предоставя на администратора на търговеца.

Защо е важно

Намаляване на риска и отговорността

Разделянето на идентификационните данни намалява обхвата на потенциално нарушение на сигурността. Ако ключ за плащане бъде прихванат от изходен код на уебсайт, нападателят не може да го използва за изтегляне на средства или достъп до исторически записи на транзакции.

Ключът на касиер остава защитен в сигурен бекенд, като гарантира, че само оторизирани сървърни среди могат да изпълняват финансови движения, което е критична защита срещу често срещани атаки с инжектиране.

Опростено съответствие с PCI DSS

Чрез използването на ключове за плащане за обработка на данни на картодържателя чрез хоствани полета или компоненти, търговците обикновено се квалифицират за намалено натоварване за съответствие, като SAQ A или SAQ A-EP.

Ключът на касиер гарантира, че чувствителните данни се обработват в токенизиран формат на бекенда, премахвайки необходимостта търговецът да съхранява, обработва или предава необработена информация за кредитни карти на собствените си сървъри.

Приложения

Уеб приложения за електронна търговия

Търговците използват ключове за плащане, за да вградят сигурни форми за плащане директно в своите уебсайтове, докато ключът на касиер се съхранява в тяхната бекенд среда, за да финализира прихващането на средства, след като поръчката бъде потвърдена.

Нативни мобилни приложения

Мобилните разработчици използват ключове за плащане в iOS или Android приложения, за да събират сигурно подписи за плащане, разчитайки на сървърни ключове на касиер за управление на сложната логика на многовалутно уреждане и повтарящо се таксуване.

Абонамент и повтарящо се таксуване

След като първоначалният ключ за плащане събере данните за картата, ключът на касиер се използва за установяване на рамка за транзакции, инициирани от търговеца (MIT), което позволява автоматични подновявания без допълнителна намеса на клиента.

В числа

90%
Намаляване на обхвата на PCI

Индустриалните стандарти предполагат, че прехвърлянето на събирането на данни към хоствани компоненти чрез клиентски ключове може да намали броя на приложимите изисквания на PCI с над 90 процента.

<2 days
Време за интеграция

Стандартизираните архитектури, базирани на ключове, обикновено позволяват на разработчиците да внедрят основен сигурен поток за плащане в рамките на приблизително два работни дни време за разработка.

100%
Защитени транзакции

Професионалните платежни шлюзове изискват 100 процента от заявките от страна на сървъра да бъдат удостоверени чрез частен ключ, за да се гарантира целостта на жизнения цикъл на транзакцията.

Свързани термини

PCI DSS
Стандарт за сигурност на данните в индустрията за разплащателни карти, мандатираната от схемата рамка за обработка на данни на картодържатели.
Токенизация
Заместване на чувствителни данни на картата с нечувствителна заместваща стойност, която може да бъде съхранявана и използвана многократно без обхват на PCI.
Платежен шлюз
Технически слой, който криптира картови данни, препраща заявки за оторизация към купувач и връща резултата на търговеца.
Картов трезор
Съхранение на токенизирани картови данни, съвместимо с PCI-DSS, което позволява на търговец да таксува карта отново, без да съхранява PAN.
Трансакция, инициирана от търговеца
Такса, инициирана от търговеца срещу предварително съхранени данни, без присъствието на картодържателя.
Трансакция, инициирана от картодържателя
Трансакция, инициирана от картодържателя в реално време, обикновено първата такса, която установява данни в файл.
Ready to route with Ключове за плащане и ключове на касиер?

Talk to our team about a live rollout on your acquiring stack.

Кандидатствайте сега

Какво получавате с Ключове за плащане и ключове на касиер

  • Изолирайте дейностите от страна на клиента от чувствителни административни функции на бекенда за подобрена сигурност
  • Минимизирайте излагането на PCI DSS, като гарантирате, че необработените данни за карти заобикалят сървърите на търговеца
  • Разрешете компонентите за плащане на предния край, използвайки ограничени, публично достъпни идентификационни данни за ключ за плащане
  • Изпълнявайте сигурни сървърни прихващания и възстановявания на суми с удостоверени заявки за ключ на касиер
  • Поддържайте гранулиран контрол на достъпа до конкретни API крайни точки и транзакционни операции
  • Поддържайте широк набор от фронтенд рамки, без да рискувате излагане на идентификационни данни на бекенда
  • Намалете вероятността от измамни преводи на средства чрез компрометиран код от страна на клиента
  • Улесняване на сигурното токенизиране на данните на картодържателя в момента на първоначално въвеждане
  • Разрешаване на инициирани от търговеца транзакции за абонаментни модели, използващи сигурно удостоверяване на бекенда
  • Осигурете ясни одиторски следи както за клиентски сесии, така и за действия за управление от страна на сървъра
See Ключове за плащане и ключове на касиер on your acquiring stack.

A short scoping call, then a written plan for your MIDs.

Кандидатствайте сега

Въпроси относно Ключове за плащане и ключове на касиер

Каква е основната разлика между ключ за плащане и таен API ключ?

Ключът за плащане е предназначен за използване в публични среди, където кодът е видим, като например браузър. Той има изключително ограничени разрешения, обикновено може само да създава платежен токен.

Тайният API ключ, или ключът на касиер, се използва за операции от страна на сървъра и има правомощието да премества пари, да извършва възстановявания на суми и да достъпва чувствителни данни на търговеца.

Разделянето на тези ключове гарантира, че дори ако публичен ключ бъде копиран, основните финансови функции на търговския акаунт остават защитени зад удостоверяване от страна на сървъра.

Може ли ключ за плащане да се използва за извършване на възстановяване на сума или анулиране на транзакция?

Не, ключовете за плащане са специално ограничени, за да предотвратят всякакви операции, които включват движение на средства от търговския акаунт.

Възстановяванията на суми, анулиранията и прихващанията изискват използването на ключ на касиер, който трябва да се пази в тайна и да се използва само в сигурна сървърна среда.

Тази защита е умишлена и предотвратява манипулирането на кода от страна на клиента от злонамерени лица, за да предизвикат неоторизирани финансови отмени или експорт на данни от платежния шлюз.

Защо тази система с два ключа е необходима за съответствие с PCI DSS?

Съответствието с PCI DSS се фокусира върху начина, по който се обработват данните на картодържателя. Чрез използването на ключ за плащане за улесняване на токенизирането на данни за карти директно от браузъра на клиента до платежния процесор, търговецът никога не докосва необработените данни.

След това ключът на касиер позволява на търговеца да работи с този токен. Това разделение е това, което позволява на търговеца да използва опростени въпросници за съответствие, тъй като техните системи никога не притежават чувствителна информация като PAN в ясен текст.

Как трябва да се съхраняват ключовете на касиер в инфраструктурата на търговеца?

Ключовете на касиер трябва да се третират като изключително чувствителни идентификационни данни. Те никога не трябва да бъдат твърдо кодирани в изходни файлове или съхранявани в системи за контрол на версиите като Git.

Вместо това те трябва да се управляват с помощта на променливи на средата или специализирана услуга за управление на тайни.

Достъпът до тези ключове трябва да бъде ограничен до конкретните сървърни инстанции, които се нуждаят от тях, за да комуникират с платежния процесор за финализиране на транзакции и отчитане.

Какво се случва, ако ключ за плащане бъде изтекъл или компрометиран?

Ако ключ за плащане бъде компрометиран, въздействието обикновено е ниско в сравнение с изтичане на таен ключ.

Нападател потенциално може да използва ключа за изпращане на нежелани данни или да се опита да създаде токени чрез MID на търговеца, но не може да достъпи съществуващи данни за клиенти или средства.

Въпреки това, все още е стандартна практика да се ротира изтеклият ключ за плащане, за да се предотврати всякаква неоторизирана употреба на фронтенд активите на търговеца и да се поддържат чисти дневници на транзакциите.

Поддържат ли ключовете на касиер различни нива на разрешение въз основа на потребителя?

Докато самият ключ на касиер представлява високо ниво на сървърни идентификационни данни, индустриалните стандартни шлюзове често позволяват създаването на множество ключове с различни обхвати.

Например, един ключ на касиер може да бъде ограничен до достъп само за четене за отчитане, докато друг може да има правомощието да обработва прихващания и възстановявания на суми.

Това следва принципа на най-малко привилегии, като гарантира, че всяка част от бекенд системата на търговеца има само разрешенията, от които се нуждае, за да функционира.

Започнете

Готови ли сте за скорост?

Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.

Кандидатствайте сега
Кандидатствайте сега