{"id":18887,"date":"2019-09-03T11:00:08","date_gmt":"2019-09-03T09:00:08","guid":{"rendered":"https:\/\/www.intellias.com\/?p=18887"},"modified":"2024-04-29T12:47:45","modified_gmt":"2024-04-29T10:47:45","slug":"how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study","status":"publish","type":"blog","link":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/","title":{"rendered":"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study"},"content":{"rendered":"<p>From a technical standpoint, a payment transaction is some unit of work performed in distributed systems. Every database transaction has <a href=\"https:\/\/www.geeksforgeeks.org\/acid-properties-in-dbms\/\" target=\"_blank\" rel=\"noopener noreferrer\">ACID properties<\/a> \u2013 they are atomic, consistent, isolated and durable. But when it comes to payments, transactional consistency means that a transaction can go through without any issues (even if the user messed up something).<\/p>\n<p>Here\u2019s a quick example to illustrate this point: You are PSP (payment service provider) such as PayPal. Some user wants to send $25 to an eBay seller. So when the person clicks that \u201cpay\u201d button, several things happen behind the hood:<\/p>\n<ul>\n<li>The user transaction gets registered in the system.<\/li>\n<li>The system proxies this transaction request to acquiring bank.<\/li>\n<li>And then it patiently waits for notification from the bank that the transaction went through alright.<\/li>\n<\/ul>\n<p>But then things suddenly go awry. Instead of one notification, we got two:<\/p>\n<ul>\n<li>One from the bank stating that the transaction was processed.<\/li>\n<li>Another one from our system saying that the user clicked the cancel button during processing or hit page refresh (or otherwise interfered with the process).<\/li>\n<\/ul>\n<div><a href=\"\/new-age-in-banking-whitepaper\/\" class=\"whitepaper-banner wow fadeInUp\">\n\t\t\t<div class=\"whitepaper-banner__icon\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/cover-79x81.png\" alt=\"cover-79&#215;81\" width=\"79\" height=\"81\" ><\/div>\n\t\t\t<div class=\"whitepaper-banner__info\">\n\t\t\t\t<div class=\"whitepaper-banner__info-text\">\n\t\t\t\t\t<div class=\"whitepaper-title\">NEW AGE IN BANKING WHITEPAPER<\/div>\n\t\t\t\t\t<div class=\"whitepaper-description\">How banks can switch to more profitable operating models<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<span class=\"whitepaper-btn btn-filled\"> Download now <\/span>\n\t\t\t<\/div>\n\t\t<\/a><\/div>\n<p><b>Now there\u2019s a problem:<\/b> we have a transaction that\u2019s, at the same time, processed and cancelled. Here you go \u2013 that\u2019s a prime example of payment transaction inconsistency.<\/p>\n<p>But now we need to figure out which one is correct. And that\u2019s somewhat challenging as those two actions were processed in parallel.<\/p>\n<p>When we don\u2019t have a guarantee of consistency in our system, we can have acid in databases but still not have strong consistency guarantee in distributed systems. As a result, we have a three-way inconsistency between <b>our system, customer and acquiring bank.<\/b><br \/>\n<img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-18888\" src=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency.jpg\" alt=\"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study\" width=\"770\" height=\"450\" srcset=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency.jpg 770w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency-300x175.jpg 300w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency-768x450.jpg 768w\" sizes=\"(max-width: 770px) 100vw, 770px\" \/><\/p>\n<h2>The technical fix: transaction locking<\/h2>\n<p>To solve this conundrum, we can do one great thing: apply a lock on transaction entity when we perform any operation with it. Locking gives us the guarantee that only one action can be processed at any given time.<\/p>\n<p>If that&#8217;s the case, here&#8217;s how the previous scenario would unroll: after the user hits cancel, we place a lock on transaction to cancel it. At the same time, the bank gets in line to process that transaction. After it acquired lock to proceed, our system already knows that the transaction is cancelled. So we send that info to the bank and it rolls back the transaction.<\/p>\n<p>Everyone\u2019s happy.<br \/>\n<img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-18890\" src=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency-2.jpg\" alt=\"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study\" width=\"770\" height=\"450\" srcset=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency-2.jpg 770w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency-2-300x175.jpg 300w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/customers-data-consistency-2-768x450.jpg 768w\" sizes=\"(max-width: 770px) 100vw, 770px\" \/><\/p>\n<p>Now let&#8217;s move on to the technical part of this post: a quick case study showing exactly how distributed locks can be applied towards payment transactions to ensure consistency.<\/p>\n<h2>How to use distributed locks to achieve data consistency in payment processing<\/h2>\n<p>Let\u2019s define how to implement distributed locks with .NET Core and Apache ZooKeeper and how to ensure payment data consistency. But first, here are some key terms first, we\u2019ll be using in this case study.<\/p>\n<h3>What\u2019s a distributed lock?<\/h3>\n<p>A distributed lock is just a primitive that allows different processes operate with shared resources in mutually exclusive way inside a <b>distributed<\/b> environment. So, basically, it\u2019s the same locks we use in scope of operating systems but designed to work in a distributed environment.<\/p>\n<h3>Why do we need distributed locks?<\/h3>\n<p>For two good reasons:<br \/>\n<b>Efficiency:<\/b> adding a lock means that no piece of work is done twice, which may result in minor errors in the system \u2013 executing scheduled jobs, processing some events like user registration and activation, and we\u2019ll not use more computing resources that we need. Hence, our system is effective and fast.<\/p>\n<p><b>Consistency:<\/b> If processing the same piece of work simultaneously can result in corrupted data, locking can help prevent its execution (as illustrated in the example above).<\/p>\n<h3>What does a CAP theorem have to do with all of that?<\/h3>\n<p>A <a href=\"https:\/\/mwhittaker.github.io\/blog\/an_illustrated_proof_of_the_cap_theorem\/\" target=\"_blank\" rel=\"noopener noreferrer\">CAP theorem<\/a> is the fundamental part to distributed systems. It says:<br \/>\n<section class=\"testimonial-wrap testimonial-wrap--simple\">\n\t\t\t<blockquote class=\"testimonial-block\">\n\t\t\t\t<div class=\"testimonial-block__content\">\n\t\t\t\t<svg class=\"quote-icon\" width=\"75\" height=\"65\" viewBox=\"0 0 75 65\" fill=\"none\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\"><path opacity=\".3\" fill-rule=\"evenodd\" clip-rule=\"evenodd\" d=\"M16 29.7h10c2.4 0 4.4.8 6.1 2.5a8.5 8.5 0 0 1 2.5 6.2v17.4c0 2.5-.8 4.5-2.5 6.2a8.2 8.2 0 0 1-6 2.6H8.7c-2.4 0-4.4-.9-6-2.6a8.5 8.5 0 0 1-2.6-6.2v-32A23 23 0 0 1 7 7.4 23.1 23.1 0 0 1 23.2.6H26a2.8 2.8 0 0 1 2.9 3v5.7c0 .8-.3 1.5-.9 2-.5.6-1.2 1-2 1h-2.8a11 11 0 0 0-8.2 3.3c-2.2 2.3-3.3 5-3.3 8.2v1.5c0 1.2.4 2.2 1.2 3 .9 1 1.9 1.4 3 1.4Zm49.9 0c2.4 0 4.4.8 6 2.5a8.5 8.5 0 0 1 2.6 6.2v17.4c0 2.5-.9 4.5-2.5 6.2a8.2 8.2 0 0 1-6.1 2.6H48.7c-2.4 0-4.5-.9-6.1-2.6a8.5 8.5 0 0 1-2.5-6.2v-32a23 23 0 0 1 6.7-16.4A23.1 23.1 0 0 1 63 .6h2.9c.7 0 1.4.3 2 .8.6.6.8 1.3.8 2v5.9c0 .8-.2 1.5-.8 2-.6.6-1.3 1-2 1H63a11 11 0 0 0-8.1 3.3c-2.2 2.3-3.4 5-3.4 8.2v1.5c0 1.2.4 2.2 1.3 3 .8 1 1.8 1.4 3 1.4h10Z\" fill=\"url(#a)\"\/><defs><linearGradient id=\"a\" x1=\".2\" y1=\"32.6\" x2=\"74.5\" y2=\"32.6\" gradientUnits=\"userSpaceOnUse\"><stop stop-color=\"#45D6AD\"\/><stop offset=\".5\" stop-color=\"#5DB6E1\"\/><stop offset=\"1\" stop-color=\"#BC84CA\"\/><\/linearGradient><\/defs><\/svg>\n\t\t\t\t\t<p>In the presence of a network partition, one has to choose between consistency and availability.<\/p>\n\t\t\t\t<\/div>\n\t\t\t\t<small class=\"testimonial-block__footer\">\n\t\t\t\t\n\t\t\t\t\t<span class=\"testimonial-block__author\"> <\/span>\n\t\t\t\t<\/small>\n\t\t\t<\/blockquote>\n\t\t<\/section><\/p>\n<p>In other words, if we want to design a fault-tolerant distributed system, we can only ensure high tolerance across two out of three system properties:<\/p>\n<ul>\n<li>C \u2013 consistency<\/li>\n<li>A \u2013 availability<\/li>\n<li>P \u2013 partition<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-18892\" src=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/CAP-theorem.jpg\" alt=\"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study\" width=\"770\" height=\"450\" srcset=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/CAP-theorem.jpg 770w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/CAP-theorem-300x175.jpg 300w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/CAP-theorem-768x450.jpg 768w\" sizes=\"(max-width: 770px) 100vw, 770px\" \/><br \/>\n<em>Source: <a href=\"https:\/\/towardsdatascience.com\/cap-theorem-and-distributed-database-management-systems-5c2be977950e\" target=\"_blank\" rel=\"noopener noreferrer\">Towards Data Science<\/a><\/em><\/p>\n<p>In the case with distributed locks, we are mostly interested in Consistency property. We want all nodes in our distributed system to observe the same data at the same time. So the most recent <b>read<\/b> operation executed on any node of the system will return the result of the most recent <b>write<\/b> operation.<\/p>\n<h2>Basic distributed lock implementation using Apache ZooKeeper and .NET Core<\/h2>\n<p>So, why are we going with ZooKeeper?<br \/>\nIt has one neat advantage over other solutions. <b>ZooKeeper doesn\u2019t expose API calls to create, acquire, and release locks directly<\/b>. Instead, it exposes a file system-like API, consisting of a smaller set of calls, that enables applications to implement their own <a href=\"https:\/\/whatis.techtarget.com\/definition\/primitive\" target=\"_blank\" rel=\"noopener noreferrer\">primitives<\/a>.<\/p>\n<p>The ZooKeeper API exposes the following operations:<\/p>\n<ol>\n<li>create \/path data \u2014 Creates a znode named with \/path and containing data<\/li>\n<li>delete \/path \u2014 Deletes the znode \/path<\/li>\n<li>exists \/path \u2014 Checks whether \/path exists<\/li>\n<li>setData \/path data \u2014 Sets the data of znode \/path to data<\/li>\n<li>getData \/path \u2014 Returns the data in \/path<\/li>\n<li>getChildren \/path \u2014 Returns the list of children under \/path<\/li>\n<\/ol>\n<p>Additionally, ZooKeeper already comes with attractive <b>ZK recipes<\/b> functionality:<\/p>\n<ul>\n<li>ZK recipes allow you to build different custom usage patterns and primitives for your distributed system.<\/li>\n<li>Or, you can use pre-made recipes that are shipped with <a href=\"http:\/\/curator.apache.org\/index.html\" target=\"_blank\" rel=\"noopener noreferrer\">Apache Curator<\/a> for Java.<\/li>\n<\/ul>\n<p>Now let\u2019s move on to practicalities.<\/p>\n<p>The basic lock implementation happens the following way:<\/p>\n<ul>\n<li>To acquire the lock, each process will try to create a znode (let&#8217;s call it \/lock)<\/li>\n<li>If process 1 (P1) succeeds in creating znode, the lock is acquired<\/li>\n<li>The P1 will proceed with the execution of code<\/li>\n<li>Process 2 (P2) will need to set a watch on this znode and try to repeat the process if a znode is removed until it succeeds in acquiring the lock.<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-18894\" src=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service.jpg\" alt=\"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study\" width=\"770\" height=\"450\" srcset=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service.jpg 770w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service-300x175.jpg 300w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service-768x450.jpg 768w\" sizes=\"(max-width: 770px) 100vw, 770px\" \/><br \/>\n<em>Source: <a href=\"https:\/\/martin.kleppmann.com\/2016\/02\/08\/how-to-do-distributed-locking.html\" target=\"_blank\" rel=\"noopener noreferrer\">Martin Kleppmann \u2013 How to Do Distributed Locking?<\/a><\/em><\/p>\n<p><b>The biggest problem at this point is releasing the lock.<\/b> So what if something goes wrong with P1? Will we end up with a deadlock?<\/p>\n<p>No one wants that. So we\u2019ll have to make znode <a href=\"https:\/\/zookeeper.apache.org\/doc\/r3.1.2\/zookeeperProgrammers.html#Ephemeral+Nodes\" target=\"_blank\" rel=\"noopener noreferrer\">ephemeral<\/a>. In that case, if client P1 will lose connection to ZooKeeper service, the lock will be automatically released.<\/p>\n<p>This approach can help fix lock release, but we\u2019ll still have some issues with the way watches are implemented in ZooKeeper.<\/p>\n<p>ZooKeeper triggers all watches set for a znode when a change occurs. So for instance, if we try to acquire the lock from 1000 processes, every time the lock will be released, ZooKeeper will trigger some 1000 notifications. And this notifications&#8217; spike can increase latency for calls submitted at that time.<\/p>\n<p>We can avoid this scenario by using sequential znodes. Each ++-process will create sequential znode <b>\/lock\/lock-<\/b>. ZooKeeper will automatically give each znode a sequence number. Using this number, we\u2019ll determine which process acquired the lock (aka znode with lowest sequence number).<\/p>\n<p>The processes that didn\u2019t get the lock will set the watch on the closest znode. This way we\u2019ll have just one watch set for each znode and avoid the herd effect.<\/p>\n<p>So far, so good. We\u2019ve just implemented one of the recipes described in ZooKeeper <a href=\"https:\/\/zookeeper.apache.org\/doc\/current\/recipes.html#Shared+Locks\" target=\"_blank\" rel=\"noopener noreferrer\">documentation<\/a>. And it does look like a bulletproof recipe for a distributed lock.<\/p>\n<p>But are things always that simple with distributed systems? Nah.<\/p>\n<p>Picture this:<\/p>\n<ul>\n<li>One transaction got the lock during step 3, znode name \u201clock\/lock-0\u201d, as described in recipe documentation.<\/li>\n<li>Another transaction process created znode \u201clock\/lock-1\u201d and activated the watch on \u201clock\/lock-0\u201d.<\/li>\n<li>Some network latency crept into the connection between the first process and ZooKeeper. That process fails to send a heartbeat to ZooKeeper. As a result, the service marks the session as expired, but the process can&#8217;t receive that &#8220;session expired&#8221; notification before it reconnects. In such cases, the process will proceed with executing the code under the critical section.<\/li>\n<li>The second process receives a notification about node \u201clock\/lock-0\u201d removal and successfully acquires the lock.<\/li>\n<li>As a result, two processes hold the lock simultaneously.<\/li>\n<\/ul>\n<p>And there you have a breach in the consistency rule stating that \u201ctwo clients cannot think that they hold the same lock\u201d.<br \/>\n<img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-18896\" src=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service-2.jpg\" alt=\"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study\" width=\"770\" height=\"450\" srcset=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service-2.jpg 770w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service-2-300x175.jpg 300w, https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/lock-service-2-768x450.jpg 768w\" sizes=\"(max-width: 770px) 100vw, 770px\" \/><br \/>\n<em>Source: <a href=\"https:\/\/martin.kleppmann.com\/2016\/02\/08\/how-to-do-distributed-locking.html\" target=\"_blank\" rel=\"noopener noreferrer\">Martin Kleppmann \u2013 How to Do Distributed Locking?<\/a><\/em><\/p>\n<p>Connectivity issues are not the only reason why such a thing can happen. It could also result from a high CPU load. Or a page fault generated while reading from memory due to slow disk I\/O.<\/p>\n<p>In any case, let\u2019s take a look at how we can fix things up.<\/p>\n<h3>How to implement fencing token functionally to further improve consistency<\/h3>\n<p>A <b>fencing token<\/b> is simply unique and strictly increasing number, which we store along with the data changes in a storage layer.<\/p>\n<p>When it\u2019s in use, the storage layer will not be able to write a request using a token that is smaller than the other ones associated with the stored data. So the code can only perform and succeed with performing the write only if the fencing token is larger than the current one.<\/p>\n<p>Here\u2019s what we can do in ZooKeeper to implement a fencing token.<\/p>\n<ul>\n<li>When we create znode, we get back a Stat structure, <b>czxid<\/b> member of which is <b>zxid<\/b> of the created node.<\/li>\n<li>And we can use it as fencing token because it&#8217;s guaranteed to be monotonically increasing.<\/li>\n<\/ul>\n<p>Any requests that change the state of ZooKeeper are forwarded to the leader, who executes the request by producing a transaction. The leader assigns an identifier (<b>zxid<\/b>) to the transaction. And then those identifiers are applied to the state of servers in the order established by the leader.<\/p>\n<p>Now showcase time. Here&#8217;s how I implemented this lock primitive constructor using .NET Core and <a href=\"https:\/\/www.nuget.org\/packages\/ZooKeeperNetEx\/\" target=\"_blank\" rel=\"noopener noreferrer\">ZooKeeperNetEx nuget package<\/a>.<\/p>\n<p>A quick note on why I&#8217;m using this package: a) it supports .NET Core and async model, while the package recommended by Apache ZooKeeper is a bit outdated and has no support for read-only connections:<\/p>\n<blockquote style=\"font-size: 14px; background-color: #ffffff;\"><p>public interface IExclusiveLock : IDisposable<br \/>\n{<br \/>\nTask&lt;(bool result, bool owner, long fencingToken, CancellationToken cancellationToken)&gt; Wait(bool acquireLockOnConnectionFail = true);<br \/>\nTask Release();<br \/>\n}<\/p><\/blockquote>\n<blockquote style=\"font-size: 14px; background-color: #ffffff;\"><p>public ExclusiveLock(string connectionString, string lockPath, int connectTimeoutMs, CancellationToken cancellationToken, ILogger logger)<\/p><\/blockquote>\n<p>P.S. Check my <a href=\"https:\/\/github.com\/Spaniol\/dlock\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub<\/a> for the entire implementation example.<\/p>\n<p>Now we can pass the parameter named \u201c<b>acquireLockOnConnectionFail<\/b>&#8221; which will force eventual consistency in the system. What it does is this: if the process encounters any connection issues while attempting to acquire a lock and this parameter is <b>true<\/b>, the lock would still be acquired successfully.<\/p>\n<p>For return parameters we have:<\/p>\n<ul>\n<li><b>result<\/b> \u2013 indicates if the lock was successfully acquired or not<\/li>\n<li><b>owner<\/b> \u2013 this parameter tells us if we waited for the lock to be released by another process. If the parameter is returned as <b>false<\/b>, we can decide to not run code under the critical section, because another process already acquired and released the lock. This parameter can be used for the optimization of concurrent long-running tasks.<\/li>\n<li><b>fencingToken<\/b> \u2013 <b>czxid<\/b> returned by ZooKeeper is used for this.<\/li>\n<li><b>cancellationToken<\/b> \u2013 set in case when <b>SessionExpired<\/b> notification arrives from ZooKeeper service, or the lock acquire takes longer then passed timeout, or if the cancellation token passed while creating a lock object is set.<\/li>\n<\/ul>\n<h3>Why should you create a custom distributed look?<\/h3>\n<p>After all, there\u2019s already a ready-to-use package that provides lock implementation recommended by ZooKeeper documentation. So why bother?<\/p>\n<p>Well, there are a few solid reasons for that:<\/p>\n<ul>\n<li>That package does not provide you with a fencing token<\/li>\n<li>There is no way of setting up a timeout for the entire process of acquiring the lock. You can only set the connection timeout for the client.<\/li>\n<li>There is no way to cancel acquiring of the lock from calling code.<\/li>\n<\/ul>\n<p>Additionally, in this specific case, I needed to accomplish several other things:<\/p>\n<ul>\n<li>Optimize the system for the long-running processes, which I implemented using <b>owner<\/b> parameter in response.<\/li>\n<li>Establish a simple way for forcing eventual consistency from calling code. So if we encounter any troubles with ZooKeeper service, we can proceed with processing, even if we now that something can go wrong.<\/li>\n<\/ul>\n<h2>Wrapping it up<\/h2>\n<p>To finish this case study, I\u2019d also like to share a few extra tips for getting things right with ZooKeeper:<\/p>\n<ol>\n<li><b>Always use an odd number of nodes<\/b>. This will help optimize the resources used by cluster, allowing you to set up the size of a quorum, sufficient in case of a split brain.<\/li>\n<li><b>Opt for hosts with fast drives<\/b>. Faster drives = faster transaction processing by nodes.<\/li>\n<li><b>Disable swap on hosts<\/b>. ZooKeeper is a Java app. Disabling swap will help you troubleshoot strange ensemble behavior as when GC will kick in and try to load some pages from hard drives. And when high I\/O slows down GC to the point that other nodes in your setup will think that this node is down.<\/li>\n<li><b>And, obviously, network connectivity<\/b>. The better connection you have, the faster everything will run.<\/li>\n<\/ol>\n<hr \/>\n<p><em>In case you still have questions or need expert help with achieving data consistency in payment processing, do not hesitate to <a href=\"https:\/\/intellias.com\/contact\/\">contact us<\/a>. Our specialists will help you ace the subject.\u00a0<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Let&#8217;s talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.<\/p>\n","protected":false},"author":15,"featured_media":57080,"template":"","class_list":["post-18887","blog","type-blog","status-publish","has-post-thumbnail","hentry","blog-category-financial-data-management","blog-category-financial-services-and-insurance","blog-category-payment-processing"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v22.4 (Yoast SEO v23.2) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>How to Deal with Transaction Inconsistency in Payments<\/title>\n<meta name=\"description\" content=\"Let&#039;s talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study\" \/>\n<meta property=\"og:description\" content=\"Let&#039;s talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/\" \/>\n<meta property=\"og:site_name\" content=\"Intellias\" \/>\n<meta property=\"article:modified_time\" content=\"2024-04-29T10:47:45+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/d17ocfn2f5o4rl.cloudfront.net\/wp-content\/uploads\/2019\/09\/BP-How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study-smm-featured-im.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/BP-How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study-smm-featured-im.jpg\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/\",\"url\":\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/\",\"name\":\"How to Deal with Transaction Inconsistency in Payments\",\"isPartOf\":{\"@id\":\"https:\/\/intellias.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study.jpg\",\"datePublished\":\"2019-09-03T09:00:08+00:00\",\"dateModified\":\"2024-04-29T10:47:45+00:00\",\"description\":\"Let's talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/#primaryimage\",\"url\":\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study.jpg\",\"contentUrl\":\"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study.jpg\",\"width\":1920,\"height\":600},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/intellias.com\/#website\",\"url\":\"https:\/\/intellias.com\/\",\"name\":\"Intellias\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/intellias.com\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/intellias.com\/#\/schema\/person\/340e93af638d45b994549b7b14544b8b\",\"name\":\"Dmytro\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"How to Deal with Transaction Inconsistency in Payments","description":"Let's talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/","og_locale":"en_US","og_type":"article","og_title":"How to Deal with Transaction Inconsistency in Payments: A Technical Case Study","og_description":"Let's talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.","og_url":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/","og_site_name":"Intellias","article_modified_time":"2024-04-29T10:47:45+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/d17ocfn2f5o4rl.cloudfront.net\/wp-content\/uploads\/2019\/09\/BP-How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study-smm-featured-im.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_image":"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/BP-How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study-smm-featured-im.jpg","twitter_misc":{"Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/","url":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/","name":"How to Deal with Transaction Inconsistency in Payments","isPartOf":{"@id":"https:\/\/intellias.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/#primaryimage"},"image":{"@id":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/#primaryimage"},"thumbnailUrl":"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study.jpg","datePublished":"2019-09-03T09:00:08+00:00","dateModified":"2024-04-29T10:47:45+00:00","description":"Let's talk about data consistency during the processing of payment transactions and how distributed locks can be used to achieve it.","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/intellias.com\/how-to-deal-with-transaction-inconsistency-in-payments-a-technical-case-study\/#primaryimage","url":"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study.jpg","contentUrl":"https:\/\/intellias.com\/wp-content\/uploads\/2019\/09\/How-to-Deal-with-Transaction-Inconsistency-in-Payments_-A-Technical-Case-Study.jpg","width":1920,"height":600},{"@type":"WebSite","@id":"https:\/\/intellias.com\/#website","url":"https:\/\/intellias.com\/","name":"Intellias","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/intellias.com\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/intellias.com\/#\/schema\/person\/340e93af638d45b994549b7b14544b8b","name":"Dmytro"}]}},"_links":{"self":[{"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/blog\/18887"}],"collection":[{"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/users\/15"}],"version-history":[{"count":5,"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/blog\/18887\/revisions"}],"predecessor-version":[{"id":59974,"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/blog\/18887\/revisions\/59974"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/media\/57080"}],"wp:attachment":[{"href":"https:\/\/intellias.com\/wp-json\/wp\/v2\/media?parent=18887"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}