I have been working on an application that needs to log credit card transactions which is dependent on using an external API. Within my application, I have the concept of an invoice with a total, and a transaction that when successful credit card payment is made, deducts from this total.
This is more of a platform independent question, but I am working with Django, Python and MySQL.
My question centers mainly around the use of transactions when dealing with external API's and how to design your software to handle potential failures. Both Django and MySQL support transactions, so that in itself is not an issue, but suppose the following scenario:
Credit card submitted though the payment API
Credit card is successfully processed
This response is then logged to the database as a payment on that invoice
There is an error saving the payment to the database for one reason or another
What do you do now?
If there was not an API call involved the answer would be clear, rollback the database transaction and raise an error. But having a call to an external API complicates matters, because this is not really a way to rollback on the external API call.
I am interested if anyone has run into this issue (for credit cards, or similar types of transactions) and how they addressed the problem, or in general some approaches for software design in this case.
It's hard to manage this in software. However, if your payment gateway is calling a callback to signify that the transaction is successful, it will presumably log an error if that callback fails to complete, and you should be able to configure it to alert you in that case, perhaps by email. Then it's up to you to rectify the situation manually.
Related
I went through complete architecture of Corda and I understood that Corda works on need to know basis.
But, the confusion here is:
If user wants to report for dispute or some problem related with transactions, where he should go. As each user is a separate process and maintaining its own database, is there any admin which can see the complete transaction and can take some action in a dispute or a problem.
thanks for the question.
There is no built-in concept of an administrator or centralized node as this would cause anything we build to be highly centralized (which defeats the purpose of a distributed application)
However, it is possible to include an administrator (regulator, governing body, etc.) as an additional party to all transactions within the CorDapp. This would be done explicitly, in code, by adding the administrator party (node) as a signer on all Commands or as a non-signing party to the transactions. The administrator node would receive information regarding all transactions on the network.
We are using Authorize.NET (AIM + CIM) to process credit cards. Recently I noticed that we are getting many declined payments in transaction log. Most of them are with status "decliner by issuer", which means we don't have any specific information about why transactions are declined. I know there can be various reasons for that, and in many cases the problem lies on customer's end, but my intention is to eliminate any problem on our side and make it work as smooth as possible. In addition, my attention is brought to the fact that some people told us that their banks treated our transactions as suspicious and declined them. I want to check whether we have any problem on our end. Here are the questions I have:
Were there any changes made recently in the banking systems that may cause more transactions to be declined? Are there any known changes in bank policies or technical stuff that affect transaction status (declined or authorized)?
When user purchases a product or signs up for our services, before processing a real payment, we submit $1 transaction to validate his credit card. Then if it is authorized successfully, we void it, save his data in CIM profile and process further payments (on recurring schedule until user unsubscribes from our services). The question is can it make problems by looking suspicious for banks? Is this an acceptable way of handling payments or we should avoid it for some reason?
Is there any documentation or article specifically on the subject of getting as much successful transactions as possible, minimizing declined transactions and eliminating risk of transactions looking suspicious to banks?
We integrated Authorize.NET into our systems about 4 years ago. The code runs normal, but is there anything that is outdated / changed / improved that should be caught up by our code in terms of getting as much successful transactions as possible?
Do you have a high chargeback rate? If that's the case, some issuers may have flagged you as a suspicious merchant.
A few others points that may have an influence:
in which country are you based, and in which countries are your customers? Some banks tend to flag whole countries in their scoring algorithms.
likewise, what's your activity?
do you use 3D Secure (Verified by Visa and the like)?
do you do all the address verification etc.?
Do you get the declines on the initial authorisation, or on subsequent ones?
Also, I suppose the $1 transaction is just an authorisation, right?
Have you tried to see if the declines come from specific issuers (recognisable from the first 4 to 6 digits)?
I'm integrating with Authorize.net's ARB API. Authorize.net processes their transactions at a certain time everyday, so when people create a subscription, their transaction is not real time.
I am creating a subscription based model, does their API tell me whether their CC has been processed? Or should I put a delay on the access to my site until they have processed all the ARB transactions that day.
Thanks in advance!
You should be charging their first subscription payment via the AIM API. This will give you instant feedback as to whether or not the payment was good. Assuming it was successful you then can use ARB to create their subscription by setting the start date to be the date of their next scheduled payment.
This serves two purposes:
If the card is bad you know immediately and can have the user provide a new card while they are still on your website. Once they leave your site it gets much more difficult to get them back to correct it.
You can give them instant access without worrying about whether or not their card is approved or not.
FYI, you can use Silent Post to determine the status of payments made via ARB.
We had a debate in the office with respect to audit logging of messages received and sent via Web Services.
I am of the opinion that the entire SOAP message should not be logged in the application audit logs unless there is a requirement that states that this is required. Only salient elements of the request need to be part of the audit log as this provides evidence that is required in the audit trail.
My reasons are:
(1) Audit logs by definition are always turned on and should not be turned off. So if we take the decision of logging the entire message for audit trail they will be turned on always and can cause a huge performance impact during production runs (particularly during peak loads)
(2) If the business/technical requirement does not explicitly state this as a requirement this is an un-necessary overhead. If information is required, the run-time engines tracing capability can be used to turn on/off to get the SOAP messages.
What are the generic thoughts of experts in this space.
Thanks,
Manglu
Don't confuse auditing with logging. If there is a requirement for auditing then you need to perform auditing.
Since auditing is typically required for legal or policy reasons you need to understand what actions and activities need to be logged as well as what data needs to be logged. This is not a technical decision but needs to be determined by the business. Once you have your requirements then you can project your audit volumes and design your application to take these into account (e.g. performance, storage, etc.).
If you think you have an auditing requirement but it is not explicitly stated then ask for clarification. You don't want to find this out only after you have been sued.
If you truly have an auditing requirement then you should probably audit the entire soap request message as well as the response. This is to support non-repudiation.
As an example let's say that you have a health care application and only audit the key information: personal identifiers (e.g. SSN) and whether the patient is allergic to penicillin. But what happens when a patient dies because is allergic to penicillin was false when it shouldn't have been? The audit logs are checked and you say that you were sent a value of false for that patient but the other system says that they actually sent you a value of true and that you must have a problem with your system. In this scenario what you need to do is to show the exact message that was sent to the web service and that because it was signed by the service consumer you can prove that it came from them and also prove that the data in the message is correct. Then you would follow that information through your system via the audit logs.
Of course, it all goes back to the requirements; if the business finds that only auditing x and y satisfies whatever legislation or policies then go with that.
I know from experience that logging it all can lead to pretty huge files or a lot of data if kept on database. It's very helpful during development time, but in production it becomes a problem. I would suggest logging as you said. But be aware of a situation I came across: We were providing a webservice for 3rd-party companies use. When there's some dispute about who's fault is the error. We needed the exact SOAP message to prove that it wasn't our fault. I don't know if this scenario applies to you.
I've been tasked with setting up a society's website. I'm a full time Django (at al) web developer so I was happy to take on the task.
Going through the specs, they want to control memberships so that all applications need a "second" (read: sponsor, referee, etc) and then they need to pay a subscription fee to be part of the club.
This club has a number of events with variable ticket prices for lunches and talks to name two. Only members are allowed to see the price per ticket and therefore only members are allowed to buy the tickets.
I had originally planned on farming the event management off to EventBrite and pulling the upcoming events back to the website through EB's API but this members-only constraint looks like something EventBrite can't do.
Then there's processing members subscriptions. I had hoped to allow anybody to register a django.contrib.auth account but leave subscription payment offline but the client would be happier if they could mark accounts as "members", store the subscription data in the database and let the members pay online.
Like with EventBrite, I was hoping I could store rough membership data (whether or not they're allowed to subscribe, a unique token for the user on the API service, their level of membership and their membership's expiry) and there'd be something I could post users off to to process their subscription payment.
I basically don't want to touch any payment systems. Even something as simple as Paypal+IPN is something I'd rather not do (I can and have in the past on other projects) but it's the layer of management that I'd have to build around it (messaging members, creating recurring events, etc) that I'd like to farm out to a third party... Even if they do want an additional percent of the payments processed.
Do any of you know any suitable APIs that cover membership or events or both?
Or is this so complex that I should give up hoping for external help and just knuckle down and do it myself?
I think the google search you are looking for is online membership management. I don't know if any of them play particularly nicely with Django/python, but some of them do include APIs. Almost all of these are companies that charge, either for the system, or on a per-user basis.
If you don't mind installing something yourself, CiviCRM is a free, open source solution that I found with a bit of googling. It's integrates with either Joomla or Drupal (so probably PHP-based). You'd have to put the payment processing in yourself, but it does support payments using PayPal which would take handling payments mostly out of the equation. If you can, choose PayPal Express rather than PayPal Website Payments Pro since you may need to be PCI-DSS compliant to use the latter.