What do the n and m stand for in the PayPal API variables like L_PAYMENTREQUEST_n_NAMEm - api

Try as I might, I can't seem to find what the n and m stand for in the api variable request format above. I'm guessing m stands for different items, but not sure what n stands for.

'n' is the number of your payment request. If you have one payment request going on at a time, this will be 0. If you have multiple (if you want to use parallel payments, for example), it would be 0 for the first payment request, 1 for the second, et cetera.
'm' is the specific product within that payment request.
E.g.
// First payment request
PAYMENTREQUEST_0_SELLERPAYPALACCOUNTID=test#example.com
PAYMENTREQUEST_0_AMT=10
L_PAYMENTREQUEST_0_NAME0=Test+product
// Second payment request
PAYMENTREQUEST_1_SELLERPAYPALACCOUNTID=test#anotherexample.com // Recipient of this payment request
PAYMENTREQUEST_1_AMT=5 // Total of all products combined in this payment request
L_PAYMENTREQUEST_1_NAME0=Test+product+2 // Name of the first product/item in this payment request
L_PAYMENTREQUEST_1_AMT0=2.50 // Price of this one product
L_PAYMENTREQUEST_1_NAME1=Test+product+3 // Name of the second product/item in this payment request
L_PAYMENTREQUEST_1_AMT1=2.50 // Price of this one product
Source: https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ECParallelPaymens

Related

AuthorizeNET CIM Payments

I have moved Authorize.NET AIM to CIM. I have two questions to solve:
In Authorize.NET live account I can see two transaction for one transaction one is 0$ voided transaction and other one is real transaction, can I avoid 0$ transaction or it is for what?
$email_address = 'user' . time() . '#domain.com';
$description = 'Monthly Membership No. ' . md5(uniqid(rand(), true));
$customer_id = substr(md5(uniqid(rand(), true)), 16, 16);
// Create the profile
$cim->setParameter('email', $email_address);
$cim->setParameter('description', $description);
$cim->setParameter('merchantCustomerId', $customer_id);
$cim->createCustomerProfile();
In the above code can we sent customer real email instead of generated email?
will it be a compliance issue?
The $0 transaction is to verify the credit card is valid before creating the customer payment profile. No, you cannot stop it from happening and you want this to occur as it allows you to get immediate feedback if a payment profile is invalid. That way you can react to it immediately rather then waiting for their first payment to fail.
Yes, you can, and should, send the correct customer email. That random email is just an example to show you how it works. The same goes for the $description and $customer_id fields as well.

Bigcommerce API - Create Shipment - Include all Items

according to the documentation, the Create Shipment method requires the property "items" - an array of the items being shipped, for example:
{
"tracking_number": "EJ958083578US",
"comments": "Ready to go...",
"order_address_id": 1,
"items": [
{
"order_product_id": 15,
"quantity": 2
}
]
}
In our business, a shipment almost invariably contains ALL items from the relevant order.
That being the case, is there a way to create a shipment without listing all items (which would require iterating over the product line-items)? Or, alternatively, a way to include all items by default (without iterating)?
We are simply wishing to automate the process of adding tracking numbers to orders - which (as a manual process) involves uploading a csv with [order_number: tracking_number] - i.e. it self-evidently assumes that all items are being shipped. The API seems not to include that (very sensible) option, but I may be wrong.
From Bigcommerce Support:
There is not a way to add a tracking number without adding a shipment nor a way to default the shipment to include all products. This is a helpful suggestion though that I will be passing on to our Product Team for possible implementation into future versions of the API.
Unfortunately for now it is necessary that you GET to the products subresource of an order and iterate over all of the products to pull their 'id' values and 'order_address_id' values so you can generate your POST request to the shipment subresource. It is not necessary to make a GET request to the shipping address subresource directly unless you want the details of that shipping address. It is also not necessary to make a GET request to the base order object unless you want details found there or you are looking to automate the process of checking for orders ready to ship.
So assuming you know an order ID that you want to ship it should only take 2 requests total to both GET the products subresource and then POST to the shipment resource.

How can I use Stripe to delay charging a customer until a physical item is shipped?

I'm in the process of building an online marketplace which sells shippable goods. The site will be similar to Etsy, which will connect merchants with buyers.
I'd like to be able to charge a customer's card ONLY when an item is shipped by a merchant to avoid chargebacks and provide an Amazon-like payment experience. This will also help us avoid chargebacks and payment disputes in case a merchant is slow to ship or flakes out. In some cases, the goods will take more than 7 days to be custom manufactured and shipped out
Here's an example timeline:
1/1/2014 - Customer adds $75 worth of items to their cart and clicks "buy". Enters credit card info.
1/1/2014 - Customer's card is verified and a $75 temporary hold is placed on their card. Order is sent to merchant for fulfillment.
1/14/2014 - Merchant ships goods to customer and adds shipping tracking info
1/14/2014 - Customer's card is charged for the full amount and merchant receives $75 minus fees.
I plan to use Stripe Connect for payment processing, but am not sure how to delay capturing a payment for more than 7 days. Any thoughts? I don't want to aggregate the funds under my own account and use payouts since this will likely run afoul of money transmission laws. Any help would be appreciated!
EDIT: It looks like Quora has a similar question here , but the answers don't seem to deal with the case where a merchant ships out the item but the payment fails.
After further research, it seems there's no way to delay capturing a charge past the 7 day authorization window.
But here's one way to delay a charge:
Tokenize a credit card using the stripe.js library
Create a new stripe customer passing in the token as the "card" param
An example from the Stripe FAQ: https://support.stripe.com/questions/can-i-save-a-card-and-charge-it-later
Note that the longer you wait between tokenizing a card and actually charging it, the more likely your charge will be declined for various reasons (expired card, lack of funds, fraud, etc). This also adds a layer of complexity (and lost sales) since you'll need to ask a buyer to resubmit payment info.
I'd still like to confirm that a certain amount can be charged (like a "preauthorization"), but this lets me at least charge the card at a later date.
Celery has built a service to help you do this with Stripe. They are very easy to use, but note that they charge 2% per transaction.
actually you can save user token and pay later with tracking info
# get the credit card details submitted by the form or app
token = params[:stripeToken]
# create a Customer
customer = Stripe::Customer.create(
card: token,
description: 'description for payinguser#example.com',
email: 'payinguser#example.com'
)
# charge the Customer instead of the card
Stripe::Charge.create(
amount: 1000, # in cents
currency: 'usd',
customer: customer.id
)
# save the customer ID in your database so you can use it later
save_stripe_customer_id(user, customer.id)
# later
customer_id = get_stripe_customer_id(user)
Stripe::Charge.create(
amount: 1500, # $15.00 this time
currency: 'usd',
customer: customer_id
)
Stripe release a delay method to place a hold without charging. https://stripe.com/docs/payments/capture-later
<?php
require_once('stripe-php/init.php');
\Stripe\Stripe::setApiKey('your stripe key');
$token = $_POST['stripeToken'];
$stripeinfo = \Stripe\Token::retrieve($token);
$email = $stripeinfo->email;
$customer = \Stripe\Customer::create(array(
"source" => $token,
"email" => $email)
);
?>

Posting credit to a bank account uri

If I already have the bank account token (id returned by balanced.js), do I need to do a get to credit the account?
The documentation at:
https://docs.balancedpayments.com/current/api.html?language=php#credit-an-existing-bank-account
says: To credit an existing bank account, you simply pass the amount to the nested credit endpoint of a bank account. The credits_uri is a convenient uri provided so that you can simply issue a POST with the amount and a credit shall be created.
But the example given below it, does a get on bank account first and then a credit.
How do I post to the credits_uri with the amount and other parameters without first doing a get?
If you don't want to get a GET first, you would need to store the credits_uri of the bank account in question and then POST directly to that. e.g.
$credit = new \Balanced\Credit(array(
"uri" => "/v1/bank_accounts/BA123123/credits", // the credits_uri from the bank account
"amount" => 100
))->save();

Proper resource names of a REST API

Let's say we are making an invoice API. What is a more appropriate resource?
GET
paid_invoices
due_invoices
all_invoices
or
GET
invoices/all
invoices/due
invoices/paid
Additional question: If your API allows marking invoices as paid what's the proper resource?
PUT //where 3 is the id
invoices/3
or
PUT
pay_invoice/3
I would say:
GET /invoices returns all invoices;
A filter can return either paid or due invoices: GET /invoices?state=paid where state can be paid or due.
To mark an invoice as paid, you can either set the corresponding state to your resource, and then you just have to update (replace actually) it using PUT /invoices/<id>.
Alternatively, you can patch your resource: PATCH /invoices/<id>. This method requires a diff like state=paid for example.
It's just a matter of what you want to send to your API (a complete resource, or just the change to apply).
A non-REST solution could be to perform a PATCH request to /invoices/<id>/paid. It's not pure REST but it's ok.