Payment Api Request

[dovid]

היום יצאה גירסה 68 של כרום.
מלבד פיצרים נחמדים למתכנתים כמיטב המסורת בכל גירסה, ישנו שיפור משמעותי שישפיע על חוויית הקניה באינטרנט וחשוב כמתכנתים להכיר אותו.

מדובר בPayment Request API, שזה תקינה חדשה שנכנסה לW3C והיא כבר מיושמת נכון לרגע זה בכרום (שיצא היום), ובEdge. אפשר לראות את הסטטוס פה: https://caniuse.com/#feat=payment-request

התקינה הזאת מסדירה API שבעזרתו הקוד של האתר פונה לדפדפן, שהוא יסדר את תהליך התשלום מול המשתמש וייתן לו את התוצאות (פרטי תשלום ויעד משלוח וכו'). זה דומה לalert בה אנו מבקשים מהדפדפן להציג הודעה, כך פה נשתמש בדפדפן להסדיר את כל העסק השחור של מספר אשראי, שלוש ספרות בגב הכרטיס וכו' וכו'. כמובן שהדפדפן יציע למשתמש (כמו שכבר קיים כיום חלקית) לשמור את כל הפרטים הללו. הלקוח רק יצטרך להחליט אם הוא קונה, ולא אם הוא טורח לקנות.

מה זה כ"כ משנה? אוהו. צופים שזה יגדיל את הקניות באינטרנט בהמון המון כסף. עד היום, כשלקוח מגיע לשלם באתר, דבר ראשון הוא יודע שהוא צריך להקליד ולהקליד ולקוות שהכל בסדר והוא לא טעה. אם מדובר באתר שהוא לא קנה בו בעבר או לפחות לא לעיתים קרובות, הוא נדרש לעשות היכרות עם השדות מיקומם ומשמעותם וכו'. הוא מפחד ללחוץ על אישור כי הוא לא בטוח עם נושא המשלוח בא אחרי או שהוא כבר פספס, תוכלו לקרוא בהרחבה על ההבדל הגדול מבחינת חויית המשתמש פה: https://developers.google.com/web/fundamentals/payments/ עריכה, לינק עברית: https://support.google.com/partners/answer/7336433?hl=iw

בקיצור המעלות הם: מהירות (פרטים שמורים בדפדפן), עקביות (כל התשלומים באותו הממשק), נגישות (הדפדפן יעשה את העבודה השחורה עבורכם!).
הדפדפן אחראי גם לולדיציה של הפרטים (ברמת צד לקוח כמובן), המספר והתוקף וכדומה.

איך זה עובד:
https://developers.google.com/web/updates/2018/06/payment-handler-api
דמו: https://paymentrequest.show/demo/

[clickone]

@dovid מי ערב שמישהו לא ייצור דפדפן דמה ויחזיר נתונים כאילו בוצעה עסקה תקינה / ישנה את הסכום שחוייב בפועל ויחזיר מה שצריך אפילו שבפועל שלח סכום קטן בהרבה?
ובמילים אחרות, על מי האחריות?

[dovid]

@clickone אמר בChrome 68, Payment Api Request:

@dovid מי ערב שמישהו לא ייצור דפדפן דמה ויחזיר נתונים כאילו בוצעה עסקה תקינה / ישנה את הסכום שחוייב בפועל ויחזיר מה שצריך אפילו שבפועל שלח סכום קטן בהרבה?
ובמילים אחרות, על מי האחריות?

הדפדפן סה"כ אוסף פרטים (טקסט ומספרים) מוודא אותם ונותן אותם לקוד שביקש אותם.
הקוד בשלב הזה שולח את האמור לשרת שמנסה (אם הוא רוצה...) לחייב, והוא נותן לדפדפן תוצאת הצלחה או כישלון - גם זה עם סטנדרטיזציה של שגיאות (גם אם אתם באתר סיני תופיע שגיאה ברובה בעברית).

[clickone]

@dovid
לא בדקתי שם את הקוד לעומק.
אבל ממש מוזר לי שהדפדפן ייתן לי את המספר אשראי.
ולכן אני מניח שהוא לא מביא לי את המספר אשראי.
כך או כך זה נשמע לי חור. ובטח אני מפספס משהו

אם הוא מביא לי את מספר האשראי אז אוי ואבוי... (היום כשאני מחייב אשראי אז אין לי דרך [רק עקרונית ] לדעת את מספר האשראי של הלקוח.)
ואם הוא לא מביא, אלא מביא לי רק איזה מספר אישור, אז מי ערב לבעל האתר שלא יכתבו או ישכתבו איזה דפדפן שיביא מספר אישור בלי ללכת באמת לחברת האשראי?

בקיצור, אני בטוח מפספס משהו. השאלה רק מה...

[dovid]

@clickone אמר בChrome 68, Payment Api Request:

@dovid
לא בדקתי שם את הקוד לעומק.
אבל ממש מוזר לי שהדפדפן ייתן לי את המספר אשראי.
ולכן אני מניח שהוא לא מביא לי את המספר אשראי.
כך או כך זה נשמע לי חור. ובטח אני מפספס משהו

אם הוא מביא לי את מספר האשראי אז אוי ואבוי... (היום כשאני מחייב אשראי אז אין לי דרך [רק עקרונית ] לדעת את מספר האשראי של הלקוח.)
ואם הוא לא מביא, אלא מביא לי רק איזה מספר אישור, אז מי ערב לבעל האתר שלא יכתבו או ישכתבו איזה דפדפן שיביא מספר אישור בלי ללכת באמת לחברת האשראי?

בקיצור, אני בטוח מפספס משהו. השאלה רק מה...

תמיד מישהו חייב לקבל את מלוא מספר האשראי. זה או בעל האתר ישירות או החברה הסולקת עימה הוא עובד.
במקרה שלך, שזה חברה מורשה לאחסון אשראי בתקן PCI-DSS, אז היא שומרת את מלוא המספר, ולבעל העסק היא נותנת רק טוקן.
אם בעל העסק רוצה לעמוד בתקן מהקצה, אז הוא לא שם ממשק משלו אלא אייפרים של החברה המורשה, ובמקרה כזה האחריות לתקשורת עם הלקוח (ובכלל זה היכולת להשתמש עם הפיצ'ר האמור) עוברת לממשק המסופק באייפרים של החברה המורשה (פלאכרד למשל).

[clickone]

@dovid
כן אבל כאן אין אייפריים.
כי הדפדפן לוקח את הפרטים.
איך הדפדפן מעביר את זה לפלאכארד?
הרי יש עוד פרטים.
כמו שם המשתמש והסיסמא שלי בפלאכארד לדוגמא (שלא אמורים להיות חשופים למשתמש)

[dovid]

@clickone אמר בChrome 68, Payment Api Request:

@dovid
כן אבל כאן אין אייפריים.
כי הדפדפן לוקח את הפרטים.
איך הדפדפן מעביר את זה לפלאכארד?
הרי יש עוד פרטים.
כמו שם המשתמש והסיסמא שלי בפלאכארד לדוגמא (שלא אמורים להיות חשופים למשתמש)

האייפרים הוא דף אינטרנט לכל דבר.
עד היום הוא מכיל תיבות קלט - input בהם המשתמש המסכן צריך להזין את פרטיו בהצלחה.
כעת הוא יכול במקום להציג שדות קלט, לבקש מהדפדפן את הפרטים.
עדיין חייב להיות אייפרים, אם אתה מסתמך על סולק אחר מוסמך עם PCI-DSS.
ההמשך, כמו שהיה עד היום (למעט שגם הכישלון יכול להתנהל ע"י הדפדפן ולא ע"י שגיאה אדומה בשפה של הממשק התורן).

(הפרטים הנוספים שאתה מדבר, שהם בעצם תקשורת בין הדף המארח לאייפרים מועברים אולי כטוקן ע"י QueryString שאותו ייצרת בצד השרת. ייתכן גם שבכתובת יש מזהה לקוח בלי סודות מיוחדים).

[clickone]

@dovid
אני אשתדל לבדוק את זה לעומק ונראה
השאלה אם זה לא השקעה גדולה מדאי לממש את זה כשלא כולם עדיין תומכים בזה...

[dovid]

@clickone אמר בChrome 68, Payment Api Request:

@dovid
אני אשתדל לבדוק את זה לעומק ונראה
השאלה אם זה לא השקעה גדולה מדאי לממש את זה כשלא כולם עדיין תומכים בזה...

אתה לא יכול לממש את זה, בלי לוותר על הPCI-DSS.
מי שאמור לממש את זה במקרה של PCI-DSS, זו החברה עימה אתה עובד.

[clickone]

@dovid
לא כ"כ.
כי החברה אמורה להעביר אייפריים.
עד שהיא תממש את זה יעברו הרבה מים ולדעתי כן יש מצב שמי שבאמצע עושה משהו
טוב נראה....
אחרת אין כאן בשורה משהו......

[dovid]

@clickone לא הבנתי מה לא כל כך.
בארץ קשה לדעת אם החברות יעשו משהו בעתיד הנראה לעין.
אבל בעולם לדעתי זה ירוץ תוך כמה חודשים (איביי, אמזון וכו').

[clickone]

@dovid
לא כ"כ על מה שאמרת שאני לא יכול לממש את זה.
רק אני לא יודע אם יש צורך בזה.
באלי אקספרס (נראה לי אבל אני לא בטוח שזה שם) כבר תקופה יש משהו דומה בכרום (הוא מחייב מהכרטיס השמור)

[dovid]

@clickone אמר בPayment Api Request:

@dovid
לא כ"כ על מה שאמרת שאני לא יכול לממש את זה.

זה מחייב ויתור על תקן PCI-DSS לפחות בחלק קבלת הנתונים, שכן הנתונים נחשפים לגורם ללא הסמכה.