learn something? Intro “Clean code” - Robert Martin “DarkMarket” - Misha Glenny “Letters from a Stoic” - Seneca “I, robot” - Isaac Asimov “The last lecture” - Randy Pausch “What every body is saying” - Joe Navarro
the team ◦ But share knowledge • What release cycle? ◦ PSPs don’t care about your timeline • Chargebacks are a thing ◦ Don’t do it the last day • Webhooks are a thing ◦ Don’t leave them for last • Get the bigger picture ◦ Think business, act developer • Don’t sign first, ask first ◦ Participate in business decisions • You are also a customer ◦ Design a solution you would use • PSPs also have a product ◦ Decide wisely how to use it • Keep product calm ◦ Not every PSP is a clone • Complain with facts ◦ Too many is good • Weekly calls ◦ Force PSPs to listen • Feature checklist ◦ Fill and maintain it • Diagrams, glossaries, and docs ◦ Your memory is not that good
Find allies ◦ Devs understand each other • Define escalations ◦ Make PSPs commit to answer • Big red buttons ◦ Shut everything down in case of fire • Does it really work? ◦ Ask PSPs for a demo • Don’t idealize others ◦ You’ll be surprised, in a bad way • Test in production is a thing ◦ No chance to escape it • Feature flags ◦ Release small, test big • Fake PSP for load testing ◦ Simulate everything, even timeouts • Split infrastructure ◦ But keep cost low • Define dynamic alerts ◦ Don’t cry wolf, but cry loud and fast • Dashboards for dummies ◦ Is it down? Yes/No • Know your timeouts ◦ Keep different values in all levels • try/catch/finally { print } ◦ Log even when everything explodes
• Integrate many ◦ One is bad, too many is bad • Aggregate integrations ◦ But not too much • Make the code speak ◦ Anyone can check mappings • Reduce client-side code ◦ Instant changes for all versions • Design for extension ◦ PSP of PSP of PSP • Defensive programming ◦ Everything will fail, everything • Null, Empty, “Null”, “dummy” ◦ Check for differences • Size matters ◦ Check for limits • yyyy-MM-dd hh:mm:ss UTC ◦ Prepare for all possible formats • Numbers and currencies ◦ Always minor units, and fight it • Optional is mandatory ◦ Assume everything is mandatory • Billing and shipping address ◦ Are they different? • First, middle, and last name ◦ Separate or together?
different • SDKs are not that good ◦ Encapsulate and avoid changes • Exceptions are exceptional ◦ Don’t throw exception if you expect it • Detailed errors avoid questions ◦ Inform clients with clear error details • Validate before the PSP ◦ Don’t send requests that will fail • Async is your friend ◦ But only when necessary • Ifs are configs ◦ Avoid “if card is…”, make it generic • Implement GETs ◦ For payments and tokens, you’ll need it • Care about statement descriptors ◦ Don’t ignore them, they can help • Schemes, brands, types, etc. ◦ Know and use the differences • Credit, void, cancel, refund, blabla ◦ Every PSP has a new definition • Keep all data ◦ But secure and compliant • Log everything ◦ But log is also storage • No backoffices ◦ Keep your data in control
payment update • Store queryable JSONs ◦ Someday you’ll need that field • Ids everywhere ◦ Send all possible reconciliation • Cards tokens are a list ◦ Allow multiple tokens per card
prog893
pfn
akitoshiga
kizawa2020
shumei_ito
riyaamemiya
camiha
occhi
mohab1
takuroabe
akhino
baasie
ivargrimstad
lara
sachag
marktimemedia
malarkey
akosma
addyosmani
csswizardry
jlugia
chikuwait
carmenintech
