I am integrating one of the payment gateway to my site in PHP, Before proceeding further, As I am new to this, I have some doubts (use cases/scenarios), So I need a solution to deal with these scenarios. I have listed them here
1) How to pass unique id to payment gateway, while It considers it as a Order No, But In real scenario Order NO/ID will be generated only on successful transaction. I thought of sending a random number to Payment gateway. On successful transaction i can store in Order table.
Table: Order
1) aID:(unique, Primary, AI)
2) RandomNo(unique)
3) Order Date
Is this a good Idea
2) Which ID to be shown to user As ORDER ID either the aID or RandomNO
3) Do I need to store the Response from the payment gateway in the DB, such as Payment ID(unique), Response Code, OrderNO & Amount. How it will be useful.
4) What are the possible scenarios that can occur after payment gateway integration, And How to deal them
1) How to pass unique id to payment gateway, while It considers it as a Order No, But In real scenario Order NO/ID will be generated only on successful transaction. I thought of sending a random number to Payment gateway. On successful transaction i can store in Order table.
ANS : First of all insert the order in database before redirecting to payment gateway and use the unique id of that insertion as order id.
2) Which ID to be shown to user As ORDER ID either the aID or RandomNO
ANS : The order id as mentioned above can be shown to the user.
3) Do I need to store the Response from the payment gateway in the DB, such as Payment ID(unique), Response Code, OrderNO & Amount. How it will be useful.
ANS : Yes! You must store response from payment gateway as you may need it in future in case of any dispute.
4) What are the possible scenarios that can occur after payment gateway integration, And How to deal them
ANS : I didn't get you in this question.
Related
I'm using Menoris payment processor on CS-Cart v 4.3.9, a while ago this error has become more frequent "Payment processor response: The transaction was not sent to the host because of a duplicate order id".
I don't understand why is it happening, so I don't know where to look, I have tried to trigger the error myself but couldn't.
Check you table cscart_orders and have a look at those IDs.
I dont think you've reched the maximum limit of mysql entries in cscart_order to be duplicate (16777215 - is the maximum value for the field with the integer type).
In my opinion the problem is where you send data, consider to ask them for that.
Check this too: http://forum.cs-cart.com/topic/45830-issue-with-order-id/
Please change the code and create an unique order id for each time a customer try to pay the order, something like
ex: 12345_1
where order_id = 12345 and 1 order_repaid value
you can check how 2checkout payment gateway is doing for example ;) app/payments/2checkout.php
...
$cart_order_id = ($order_info['repaid']) ? ($order_id .'_'. $order_info['repaid']) : $order_id;
...
if Monoris doesn't accept for order_id to be string than you will need to generate and unique order_id for each time customer try to buy and attach to order_id in this way on payment return you will be able to get the real order_id and compete the payment
*[duplicate order id] - issue is happening when a customer goes to Monoris payment page and customer click cancel or get back to website and after that he goes again to pay the order
Thanks all for your answers, i have managed to solve this by adding a time stamp next to the order id
'order_id' => $processor_data['processor_params']['order_prefix'] . $order_info['order_id'] .'_'. date("G:i:s"),
I have done air ticket cancellation service. but I don't know how to refund the amount. If anyone know how to refund the balance amount. Please provide the flow of refund web-service. we used here PHP, and soap API.
Sabre has a webservice for an Automated Refunds (TKT_RefundRQ). However, the list of aircompanies supporting the Automated Refunds flow is very limited, you may find it here.
I guess in most cases you should read fare rules (cat. 16) to find out what penalties apply. You may use either StructureFareRulesRQ for structured or OTA_AirRulesLLSRQ for plain text fare rules.
Step 1:
Save your Ticket order into another table. You need to put the order value (Money) . into the table
step 2:
when somebody orders a ticket you have to Cut that ticket price and save a new price in your amount table
( Now for example You have a amount of 200$ in your amount table)
( You ordered a ticket , store that ticket ID )
(get ticket amount using Join query ) or ( You can store the amount in the order table )
Step3:
Get you amount from amount table and subtract with the order amount
Here you go... got whole idea?
Happy coding ...
I am trying to design a data structure where the class/table has multiple differentiation's withing it itself. I am not sure what to call this or if I use the right terminology.
Hopefully I can illustrate my problem with the following example:
There is a webshop and somebody buys something and goes to the check out. At the check out they can select their payment type. The customer selects cash and with what currency.
An other customer does the same but pays online with credit card.
Now I have the following mysql scheme for this situation:
**Order**
order_id
customer_id
is_paid
payment_type_id
**payment_type**
payment_type_id
payment_name
And a customer table with the usual information. But where do I save if was paid and if required information about how the customer is going to pay.
How would such a database look like and what would the queries look like?
I am not a fan of a little field within tables where the data could be anything depending on the type (or is that the way to go?) cause of querying problems.
Hopefully I am clear enough in what I am asking.
If you have a single payment for each order you want to have it attached to it, so the 'is_paid' is just fine there, as well as the payment type. In this case you want the currency there also. Cause it is independent of the payment type.
I only see problems if you want to know more info about the payment like when it was paid or if you consider a payment for more than one order at a time or even if a payment don't happen at the same time as the order and you want to separate the concepts.
To solve the 1st instead of is_paid you can have a datetime field that when it's NULL is not paid. For the 2nd and 3rd you would need some Payment entity also. For a richer model with some logic about the payment I would have something like:
**Order**
id
payment_id
...
(all sort of info about the order)
** Payment **
id
customer_id
payment_type (or payment_type_id)
payment_value
payment_currency
payment_date
...
(more info about the payment)
Depending on what you'll do with payment_type you can consider having only a value describing the type or an id for the table with more info about it as you already had.
However this will be an overkill if you just have Order 1..1 Payment, in that case just store payments info as you had, along the order.
This is subjective, but I usually have a payment type (cash, credit card, souls, etc.), a payment amount (100.00) and a payment currency (USD, CAD, MXN, etc.) fields in the order table, alternatively, and if you payment system supports it, you can add conversion factor.
I'm working on a e-commerce website. This website shall be integrated with a payment- processor. I have the following orders table.
orders(InnoDB)
-----------------------
id int PRIMARY KEY
user_account_id int
item_id int
price decimal(6,2)
payment_mode ENUM(cash,pg)
payment_status(pending,paid,lost)
order_timestamp Timestamp
When the order is placed, payment_status will be 'pending'. User is redirected to payment-processor.If the payment is authorized, payment_status shall be updated as 'paid'. If the transaction is lost (or) unauthorized payment_status shall be updated as
'lost'. I want to give user 30mins to pay. If he fails to pay within 30mins payment_status shall be updated as lost and ordered item will be cancled and available for others to book.
So, How can this be achived? How can I run a script after 30mins to update order as lost (or) should I use a cron-job every 5mins checking for lost transactions?
I would have done so, in application store pending transactions info, and with timer after 30mins update database + cron task everŅ N mins(for reliability)
UPD:
Oops, not noticed php tag. As variant, update payment status before selecting payments by status
I'm having some trouble making sense of the authorize.net Transaction Details API (documentation here). I'll try my best to be brief.
The only practical way of pulling transaction status updates from authorize (without using their 'silent post' feature, which seems like a big bag of nightmares* ), is to get a batch list of settled transactions (for let's say a day) and then pull transaction lists for every settled batch. Eg:
public function getTransactionsForDay($month = false, $day = false, $year = false)
{
$transactions = array();
$month = ($month ? $month : date('m'));
$day = ($day ? $day : date('d'));
$year = ($year ? $year : date('Y'));
$firstSettlementDate = substr(date('c',mktime(0, 0, 0, (int)$month, (int)$day, (int)$year)),0,-6);
$lastSettlementDate = substr(date('c',mktime(0, 0, 0, (int)$month, (int)$day, (int)$year)),0,-6);
$response = $this->getSettledBatchList(true, $firstSettlementDate, $lastSettlementDate);
$batches = $response->xpath("batchList/batch");
foreach ($batches as $batch) {
$batch_id = (string)$batch->batchId;
$request = new AuthorizeNetTD;
$tran_list = $request->getTransactionList($batch_id);
$transactions = array_merge($transactions, $tran_list->xpath("transactions/transaction"));
}
return $transactions;
}
$request = new AuthorizeNetTD;
$transactions = $request->getTransactionsForDay(12, 8, 2010);
$this->assertTrue(is_array($transactions));
Yet, there's a multitude of possible transaction statuses.
These appear to be 'final' and unchangeable:
communicationError
refundSettledSuccessfully
declined
couldNotVoid
expired
generalError
failedReview
settledSuccessfully
settlementError
voided
The following appear to be 'pending' statuses:
authorizedPendingCapture
capturedPendingSettlement
refundPendingSettlement
pendingFinalSettlement
pendingSettlement
underReview
updatingSettlement
FDSPendingReview
FDSAuthorizedPendingReview
authorizedPendingRelease
These, I'm not sure about:
returnedItem (?)
chargeback (?)
chargebackReversal (?)
approvedReview (?)
The getUnsettledTransactionList just dumps the last 1000 'unsettled' transactions on your lap, including declined, error, etc -- making it pretty unreliable, not mention you have to parse that junk.
So, my questions are:
What's up with the last four statuses above? Should I expect those to change or not?
Which of these go into a 'settled' batch? (settlementError AND settledSuccessfully? JUST settledSuccessfully? )
Do recurring billing transactions (documentation here) even show up in the settled batches?
Is there really no way to pull just the 'pending' transactions from authorize, ignoring all the irrelevant error, declined, etc ones? It seems necessary for recurring billing -- because otherwise, an app (in lieu of a transaction id) has no way of knowing if there's a problem with a subscription transaction, until enough time passes that you can safely assume it should have showed up in a settled batch.
* due to the two second timeout, fail-and-never-talk-to-you-again policy, plus having to rely on users to properly configure their settings
I have gotten a response from Authorize.net Here it is:
A part of the confusion with the transaction statuses is that the transaction status object is built off of a similar object that we use internally and includes ever possible transaction status in our system. Some of these status will effectively never actually be seen by you as an external developer. I've checked our public knowledge base and confirmed that we don't currently have a good list of all of the transaction statuses, so I'm working on creating one for you. I'm working with our internal developers just to confirm some details on the statuses and I'll reply with that list as soon as I can. I can answer the rest of your questions right now.
Which of these go into a 'settled' batch? (settlementError AND
settledSuccessfully? JUST settledSuccessfully? )
Within Authorize.Net, all transactions are moved into a batch when the transaction state is final. This is a significant difference in the Authorize.Net definition of a batch and the definition used by most merchant services provider. Because all of our reporting is organized into batches, it is important that all of your transactions ultimately end up in a batch.
Do recurring billing transactions ([documentation here][2]) even show
up in the settled batches?
Yes, the transactions initiated by the Automated Recurring Billing (ARB) system are treated no different from any other transaction once they are created.
Is there really no way to pull just the 'pending' transactions from
authorize, ignoring all the irrelevant error, declined, etc ones?
It seems necessary for recurring billing -- because otherwise, an app
(in lieu of a transaction id) has no way of knowing if there's a
problem with a subscription transaction, until enough time passes that
you can safely assume it should have showed up in a settled batch.
There is currently no way to pull a list of only successful unsettled transactions or of pulling only transactions that are associated with a specific ARB subscription. We are aware of this limitation and have a few ideas of how to address it, but unfortunately the only 100% reliable way of checking ARB transactions programmatically is to pull the whole batch after settlement.
I'm working towards making more of an official document for defining these fields, but I thought I would post what I have so far:
BasicTransaction Statuses
I don't think these statuses need any further explanation, but let me know if I'm mistaken.
- authorizedPendingCapture
- capturedPendingSettlement
- refundPendingSettlement
- settledSuccessfully
- refundSettledSuccessfully
- voided
- expired
- declined
Fraud Detection Suite (FDS or AFDS) Specific Responses
Both of these statuses indicate that a transaction is pending manual review by the merchant.
- FDSPendingReview
- FDSAuthorizedPendingReview
eCheck Specific Responses
- underReview - Under manual review, will be approved or declined.
- failedReview - Final status of a transaction that fails review.
- returnedItem - This will not show on an original transaction, but eCheck returns generate their own transactions with this status.
Other Errors
- communicationError - An individual transaction was rejected by the processor. This is a final transaction status.
- settlementError - A day's batch was rejected by the processor. This status is not final. The merchant should try to recover the batch.
- General Error - This is a catch-all status for any transaction status that is not otherwise defined.
Transitional Transaction Statuses
These transaction statuses occur only as a transaction is taking place. They should not be returned by the Transaction Details API.
- couldNotVoid
- approvedReview
Legacy Statuses
These transaction statuses relate to services that we have not offered for over 3 years. Because an Authorize.Net merchant account stores only 2-3 years of history, you will not see these statuses actually returned in any normal operation.
- pendingFinalSettlement
- pendingSettlement
- updatingSettlement
- chargeback
- chargebackReversal
- authorizedPendingRelease