전자 상거래 플랫폼 지불 및 결제 시스템 설계-제품 지향

앞에 적는다: 이 문장 은 작가 가 최근 배운 지불 관련 지식 이다. 지평을 보고, 모두가 제품 매니저, 금을 파는 등의 장소의 대작을 보고, 나는 발췌문을 빗어 요약했다. 이것은 단지 내 자신의 학습을 위한 것이다. 실례가 있으면 지적해 주세요. 감사합니다 ~

전체 시스템은 거래 시스템 (OMS), 지불 시스템, 청산 결제 시스템, 조정 시스템, 회계 보고서 (선택 사항) 등으로 나뉩니다.

결제 시스템은 전자 상거래 시스템의 지불을 담당하는 하위 시스템으로, 전자 상거래 플랫폼과 외부 채널 간의 모든 결제 기능 및 전자 상거래 플랫폼의 내부 계정 간 이체 기능을 지원해야 합니다. 간단히 말해서, 지불 플랫폼은 충전, 현금 인출, 이체, 환불의 네 가지 주요 기능을 구현해야 한다.

일반적으로 결제 시스템은 다음 기능으로 구성됩니다.

제 3 자 지불: 위챗 및 알리페이는 국내 모바일 결제의 대부분을 차지하므로 반드시 네트워크로 연결해야 합니다.

결제 유형에 따라 영수증은 일반적으로 즉시 입금과 보증거래 두 가지가 있는데, 지불 유형에는 이체와 은행 카드 결제가 있습니다.

전자 상거래 플랫폼에 지불 면허가 있는 경우, 직접 계정을 나눌 수 있거나, 수금 유형이 연회비와 같이 분담할 필요가 없는 거래인 경우, 즉시 수금할 수 있는 옵션이 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 스포츠명언)

전자상거래 플랫폼이 면허를 지불하지 않은 경우 2 급 상인에게 계좌를 나눠야 하는 경우 위챗 PayPal 이나 알리페이의 직불 등을 선택할 수 있습니다. 그러나 사용자가 위챗 결제를 통해 지불하는 주문은 위챗 제품을 통해서만 결제할 수 있고, 알리페이가 지불하는 주문은 알리페이를 통해서만 결제할 수 있으며, 플랫폼 도킹과 가계 영수증은 불편합니다. 따라서 전자상거래 플랫폼은 이런 방식을 거의 선택하지 않는다.

은행 카드 지불

일반적으로 전자 상거래 플랫폼은 위챗 및 알리페이에 접속하면 대부분의 지불 요구를 충족시킬 수 있으며 은행 카드에 접속하여 지불할 필요가 없습니다. 이미 지불 면허증을 구입한 대형 전자상거래 플랫폼의 경우 자체 결제 도구를 구축하려면 각 주요 은행과 도킹하여 빠른 결제 기능에 액세스하게 됩니다. 또는 일정 규모의 전자상거래 플랫폼이 있어도 은행과 직접 계약을 맺고 빠른 결제 인터페이스를 열 수 있습니다.

제 3 자 지불과 달리 은행 카드 영수증과 환불은 일반적으로 실시간으로 결제되지 않습니다. 지불 회사와 전자상가의 청구처 거래는 실시간으로 정산된 것으로, 실제로는 회사의 선불금을 지불하는 것이다.

빠른 지불

현재 시중에 나와 있는 대부분의 전자상인 앱 중 카드 결제 기능은 모두 빠른 결제 방식이다. 전자상거래 플랫폼의 경우 은행 카드의 빠른 지불 기능에 액세스해야 하는 두 가지 방법이 있습니다.

예를 들어, 전자상거래 플랫폼은 공행에 빠른 지불 인터페이스를 개통했고, 사용자는 빠른 지불을 위해 공행카드 한 장을 계약했다. 사용자가 결제한 후 결제가 성공하면 자금 공제가 해당 전자상거래 플랫폼의 산업은행 결제계좌로 들어간다. 약식 지급은 업무 유형에 따라 제한되며 업무 범위 내 업무 수금, 즉 MCC 코드만 계약할 수 있습니다.

제 3 자 지불 회사인 경우 은행과 직접 도킹할 수 없기 때문에 은련이나 은행에서 제공하는 온라인 인터페이스가 필요합니다. 사용자가 지불하면 온라인 결제 후 금액은 지불회사가 은행에 개설한 예비금 계좌로 이체됩니다.

전자상거래 플랫폼의 경우 은련과의 도킹이 훨씬 쉽고 빠르며, 대부분의 은행 카드는 한 번의 접속으로 신속하게 지불할 수 있습니다. 전기상 플랫폼 또는 지급 면허가 있는 제 3 자 지급 회사의 경우 수수료를 낮추기 위해 은행과 직접 도킹하도록 선택할 것이다.

은행 카드 빠른 지불, 먼저 카드에 서명해야 하고, 어떠한 검증도 없이 공제를 완성할 수 있다. (윌리엄 셰익스피어, 카드, 카드, 카드, 카드, 카드, 카드) 보안을 위해 전자 상거래 플랫폼은 지문, 얼굴, 문자 메시지 또는 지불 암호 인증을 증가시키며 소액 결제만 면제됩니다.

Quickpay 등록에는 세 가지 요소 (이름, 주민등록번호, 은행카드 번호) 또는 네 가지 요소 (은행이 예약한 휴대폰 번호) 가 필요하며, 신용 카드에는 유효기간과 마지막 세 자리 cvv 가 필요할 수 있습니다. 지불 회사나 전자 상거래 플랫폼은 사용자의 cvv 코드 저장을 허용하지 않습니다. 사용자는 빠른 지불 계약서에 서명하기 전에 실명 인증 이상의 인증을 완료하여 계약카드가 자신의 은행카드인지 확인해야 합니다. 국내법은 제 3 자 지급 사용자에 대한 정보 검증에 대해 3 단계, 3 급은 최고 보안 수준이며 해당 지불 한도와 지불 범위도 더욱 제한적이다.

제 3 자 지급 회사의 경우 안전, 수수료 등의 이유로 같은 은행, 본점과 다른 지점 또는 은련 등 다른 채널과 계약합니다. 카드로 계약할 때 또는 후속 지불 계약을 할 때 사용자는 SMS 검증이 필요한 채널에 서명하거나 SMS 검증이 필요하지 않은 다른 채널에 서명할 수 있습니다. 후속 사용자가 quickpay 를 사용할 경우 지불 채널 라우팅은 자동으로 가장 적합한 지불 채널을 선택하여 공제를 시작합니다. 동일한 카드에 대한 빠른 지불 한도의 경우 서로 다른 지불 채널을 사용하는 한도는 독립적이지만 총액은 카드 발행 라인의 한도를 초과하지 않습니다.

제품 측에서 빠른 지불 기능을 구현하려면 프런트엔드에 서명 카드 관리, 신규 계약 (카드 정보 입력-카드 정보 인식-계약 결과 반환), 바인딩 해제 기능이 필요합니다.

제 3 자 지불이든 빠른 지불이든, 지급 회사와 계약할 때 여러 수금 계좌를 연결할 수 있으며, 경우에 따라 업무마다 서로 다른 수금 계좌 수금을 사용하여 재무 구분을 할 수 있습니다.

은행 계좌 이체의 기본 원칙

은행 간 이체에는 슈퍼망은과 소액이체의 두 가지 종류가 있습니다. 한도 5w 이내, 개방시간 7*24 시간. 차이점은 슈퍼넷은 실시간 결제이고, 마이크로이체은행은 배치 처리이며, 준 실시간이라는 점이다. 대액 이체 5w 이상, 개장 시간은 평일 8 시 30 분-17 시 00 분 실시간 결제입니다. 은행에서 제공하는 이체 제품은 기본적으로 위의 세 가지 방법으로 포장됩니다.

전자상거래 업무의 환불, 상가 결제, 커미션결제, 공급자 대금결제 등의 업무는 모두 지불과 관련이 있다.

환불: 일반적으로 지불 후 일정 기간 (보통 3 ~ 6 개월) 동안 원래 지불 채널의 환불 기능을 사용하여 자금을 환불할 수 있습니다. 만약 당신이 시간 제한이나 부분 환불 횟수 제한을 초과한다면, 당신은 돌아갈 수 없습니다. 환불은 반품 상태를 확인하기 위해 5~7 일 (영업일 기준) 정도 소요될 수 있습니다. 은행의 경우 수수료가 공제된 청산 영수증 거래 환불이 발생하더라도 이전 수금 비용은 환불되지 않습니다. 결제하기 전에 환불하는 경우 은행은 수수료의 비례 환불을 지원할 수 있습니다. 제 3 자 지불 회사와 전자 상거래 플랫폼 간의 환불 청구는 쌍방의 협의에 의해 결정된다.

은기업 직련: 전자상이 이미 은행의 은기업 직련 제품에 접속했고, 지급 대상이 이미 은행 카드를 묶은 경우 이런 방식을 사용할 수 있습니다.

제 3 자 지급의 지급 기능: 고주파, 소액 지급 요구 사항 및 사용자가 이미 제 3 자 지급 계정에 연결되어 있는 경우 이 방법을 사용할 수 있습니다.

기업망은: 일반적으로 2B 의 대형 자금 이체에 사용됩니다. 자금 결제 또는 사용자 현금 인출.

제 3 자 지불 회사의 경우, 사용자가 언급할 때 동일한 현금 인출 계좌는 일정 금액 (금액 또는 수량) 을 받고 대량 처리를 위해 은행에 제출되므로 인출이 실시간으로 이루어지지 않을 수 있습니다.

지불의 전제는 사용자가 실명인증을 하고 실명에 해당하는 은행 카드를 바인딩하는 것이다. 바인딩 카드는 4 요소 검증이 필요하며 제 3 자 지불이 제공하는 정보 검증 인터페이스가 필요하거나 은행과 직접 도킹해야 합니다. 등록된 quickpay 직불 카드도 재검증 없이 이 계좌에서 자금을 인출하는 데 사용할 수 있습니다.

각 지불 채널마다 인터페이스 설명이 다릅니다. 향후 비즈니스 호출 및 확장 유지 관리를 용이하게 하려면 통합 결제 게이트웨이를 구축하여 비즈니스에 개방해야 합니다. 서비스가 호출되면 지불 채널도 지정하고, 지불 게이트웨이 요청 채널 라우팅도 지정하고, 미리 구성된 라우팅 규칙에 따라 가장 적합한 지불 채널로 돌아가서 지불 요청을 시작합니다.

게이트웨이에는 다양한 유형의 기능 인터페이스가 필요합니다. 일반적으로 충전, 현금 인출, 이체, 환불, 계약 조회, 실명 인증 검증 등과 같은 결제 채널 측 인터페이스 기능의 합집합입니다.

안내 라우팅: 표시 상태, 사용 가능한 상태, 표시 순서 등을 포함하여 사용자가 지불할 때 표시되는 지불 방법을 나타내는 규칙입니다. 안내 라우팅의 의미는 사용자의 지불 시나리오에 따라 사용자가 원하는 지불 방법을 선택할 수 있도록 안내하는 것입니다. 플랫폼 측 수요는 일반적으로 지불 성공률이 높고 (채널 안정성, 금액), 비율이 낮으며, 서로 다른 지불 채널 간의 업무 협력으로 인해 한도액이 제한적으로 전환되는 원인이 있습니다.

일치하는 액세스의 유료 채널이 매우 적을 때, 안내 노선의 역할은 크지 않다. 일반적으로 간단한 가중치 구성 백그라운드, 즉 정적 경로만 있을 수 있으며 사용자가 마지막으로 선택한 방법을 직접 기억할 수 있습니다.

채널 라우팅: 전자 상거래 플랫폼의 경우 제 3 자 지불에만 액세스하는 경우 채널 라우팅이 없습니다. 지불 회사의 경우 다른 은행의 빠른 지불 인터페이스와 은련 네트워크가 연결되어 있고 사용자가 선택한 은행 카드에 여러 채널이 서명된 경우 채널 라우팅은 라우팅 규칙에 따라 가중치가 가장 높은 채널에 따라 공제 요청을 시작합니다.

직접 연결이 끊어지면 지불 회사의 수금 서비스는 은련이나 인터넷 인터페이스를 통해서만 가능하므로 채널 라우팅의 의미도 약화된다. 대행 지불 업무의 경우, 지불회사는 각 주요 은행에 대리 납부 계좌를 개설하고, 은행 간 이체를 모두 동행이체로 전환하여 이체 속도를 높이고 수수료를 면제한다. 동시에, 지불 회사는 모든 은행의 준비금을 자동 또는 수동으로 관리, 모니터링 및 배치할 수 있는 준비금 관리 시스템을 갖추어야 합니다.

서비스가 지불 게이트웨이에 지불 요청을 시작할 때 지불 게이트웨이는 요청이 합법적인지 확인하기 위해 서비스 당사자를 인증해야 합니다. 지불 요청에는 일반적으로 비즈니스 ID, 지불 시간, 지불 금액, 지불 계정, 지불 클라이언트 정보, 지불 주문 정보 등의 요소가 포함됩니다. 지불 게이트웨이는 모든 요소가 합법적인지 확인해야 합니다 (예: 지불 시간이 유효기간 내에 있는지 여부, 지불 청구서가 만료되었는지 여부). 지불 계좌 상태가 정상인지, 지불서가 지급되는지, 화물이 재고가 있는지 등. 동시에 바람통제를 통해 정보를 전달해야 하며, 바람통제측은 각종 규칙에 따라 지불이 위험한지 여부를 판단한다. 풍통제는 복잡한 시스템으로, 또 다른 전문 분야에 속하므로, 여기서는 자세히 설명하지 않을 것이다.

전자상거래 플랫폼이 지불 채널에 지불을 요청하면 지불 채널은 동기적으로 또는 비동기적으로 지불 결과 정보를 반환합니다. 지불 채널이 자발적으로 결과를 반환하지 않는 경우 전자 상거래 플랫폼 측은 정기적으로 결과를 폴링해야 합니다. 동시에 전자상가는 지불 요청 정보, 결과 정보, 결과 증명서 등을 저장해야 한다. , 즉 지불 흐름 기록입니다. 지불 유수 기록은 전기상과 지불 채널 조정의 증빙이다.

지급 시스템이 지급 결과 레코드를 얻은 후에는 지급 결과를 지급 요청자에게 반환하고 회계 시스템에 해당 회계 작업을 트리거하도록 통지해야 합니다.

각 지불 채널은 거래 기록과 현금 흐름표를 일별, 월별로 생성하여 지불, 환불, 현금 인출 등의 유형으로 나눕니다. 트랜잭션 로그 파일은 정보 흐름 증명서와 같고, 자금 흐름 어음은 자금 흐름 증명서와 같습니다.

일반 은행 채널도 자금 흐름 파일을 푸시하지만 모든 은행 거래에 업무 조정 파일이 있는 것은 아닙니다. 일반적으로 청구처 거래에 대한 조정 문서가 더 일반적입니다.

전자 상거래 결제 시스템 또는 조정 시스템은 무엇을 해야 합니까?

지불 시스템은 또한 지불 상태와 금액의 일관성을 캡슐화하기 위해 업스트림 비즈니스 시스템과 조정이 필요합니다. 일반적으로 상세한 장부를 스크롤하는 방법을 채택한다.

영수증 조정 FAQ:

장기 지급: 사용자가 지급했지만 거래 시스템이 지급 성공을 확인하지 않았습니다. 이런 상황은 제때에 보충하거나 환불해야 한다. 일반적으로 업무 측 주문 상태가 지급 대기중인 경우 지급 성공으로 전환할 수 있으며, 상태가 취소인 경우 자동 환불이 가능합니다. 테스트 데이터가 프로덕션 환경에 섞여 있을 수도 있습니다. 이전의 짧은 단락 오류를 상쇄할 수도 있습니다.

약식 지불: 일반적으로 일일 절단 문제로 인해 발생하며, 게시 후 다음 회계일에 조정을 계속합니다. 또는 이전의 장기적인 실수를 상쇄 할 수 있는지 확인하십시오.

반복 지불: 일반 지불 채널은 동일한 주문에 대한 반복 지불을 허용하지 않으며, 반복 지불은 자동 환불이 가능하다는 것을 알게 되었습니다.

금액 불일치: 사용자가 지불한 후 지급 결과가 반환되기 전에 거래 시스템의 주문 금액이 변경되었을 수 있습니다.

환불 FAQ:

네트워크 문제 또는 인터페이스 문제로 인해 환불에 실패했습니다. 이 경우 자동으로 환불을 다시 제출할 수 있습니다.

상대방의 계좌 상태가 이상해서 환불이 실패하여 원래 경로를 통해 환불할 수 없고, 상대방 대신 이체/지불만 할 수 있습니다.

환불할 때 납부한 환불과 환불 비용을 누가 부담해야 하는지, 일반적으로 비례 환불입니다.

단기 오류의 경우 7 일 동안 일시 중지할 수 있습니다.

현금 인출 FAQ: 상대방의 계정 상태 이상으로 인해 환불이 실패하여 즉시 사용자에게 처리해야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 자기관리명언) 단기 오류의 경우 3 일 동안 계정을 일시 중지할 수 있습니다.

제품측은 결제 흐름, 조정 배치 기록, 오류 처리 백그라운드 등을 볼 수 있는 조정 관리 배경을 설계해야 합니다. 고정 처리 방법이 있는 오류 유형의 경우 자동으로 처리할 수 있습니다.

조합지불이란 사용자가 한 번에 여러 주문을 지불하는 것을 의미하며, 이는 전자 상거래에서 매우 흔하다. 전자상거래 업무측은 스스로 주문을 분할해야 한다. 지불 시스템에서 지불 채널의 지불 인터페이스를 사용하는 경우 지급 프로세스가 자동으로 레코드를 분할하는 것이 가장 좋은 방법입니다. 지불 채널에 통합 지불 인터페이스가 없는 경우 제거 또는 제거 안 할 수 있고, 원래 기록에 따라 간단하고 오류가 발생하기 쉬우며, 레코드를 분할하면 다른 업무 처리가 용이해집니다.

혼합지불은 잔액+빠른 지불 등 다양한 지불 방식을 통해 주문을 지불하는 것이다. 혼합 지불은 서로 다른 지불 방법에 따라 여러 지급 스트림을 생성합니다.

지불 방법에 따라 지불 성공률이 다르기 때문에 일부 지불 방식은 돈을 공제하지 못할 수도 있다. 따라서 혼합 지급은 지급 성공률에 따라 성공률이 낮은 지급 방식을 우선적으로 선택해야 합니다. 특정 지불 방법으로 돈을 공제하지 못할 경우 지불을 취소할 것인지, 전액 환불을 취소할 것인지, 아니면 다른 방식으로 사용자에게 지불을 계속할 것인지 결정해야 합니다. 모든 결제 방법 공제가 성공하면 이번 지불은 주문보다 완료됩니다. 후속 주문 환불. 부분 환불인 경우 환불료가 가장 낮은 결제 방법을 판단하고 우선적으로 선택해야 합니다.

전자 상거래 플랫폼 또는 지불 회사는 마케팅 활동을 하거나 보조금을 지급하거나 혼합 지불 방식을 사용하는 경우가 있습니다.

잔액+카드의 혼합지불은 돈세탁의 위험이 있다고 하는데, 현재는 점점 드물어지고 있다.

큰 주문의 경우 할부로 지불할 수 있고, 본질적으로 혼합지불이다.

주문이 완료되면 전자상 플랫폼은 플랫폼 커미션을 공제하고 상가에 대금을 결제해야 한다. 프로모션 서비스가 포함된 경우 프로모션 사용자의 커미션과 세금을 계산하고 프로모션 사용자에게 결제해야 합니다.

법률에 따르면, 청산 면허를 청산하지 않은 전기상은 스스로 재고자금을 가로채고 상가와 결산해서는 안 된다. 전자 상거래 플랫폼은 제 3 자 지불 회사를 선택할 수도 있고, 은행의 전자상거래 결제 제품을 사용하여 그들이 대신 대금을 보관한 다음 상가에 결제할 수도 있다. 이러한 제품은 승인을 위해 지불 채널 또는 은행에 상인 정보를 제출해야 합니다. 심사가 통과된 후 사용자는 상가 주문을 지불하고 지불을 제출하고 청산 규칙 (누구에게, 어떤 비율이나 금액) 을 보냅니다. 주문서 거래가 완료된 후 전자상측은 결산 요청을 제출하고, 지불 플랫폼은 이전 지불 시 발송한 청산 규칙에 따라 결산을 진행한다. 일부 결제 플랫폼의 경우 결제 시 전자 상거래 플랫폼이 하위 계정 객체와 금액을 지정해야 하지만 이는 다소 의심스럽다.

이러한 결제 제품을 선택할 때 다음 사항에 유의해야 합니다.

이런 제품에 접속한 후 전자상거래 플랫폼의 상가측 클라이언트는 백엔드 결제 인터페이스 도킹 외에 상가의 입고 취소 계좌 바인딩, 결제 계산서 등의 기능도 필요하다.

전자상 플랫폼의 일반적인 판매 모델은 유통, 아나운서 대리 판매, 콤비네이션, 장난꾸러기 등이다. "리셀러" 또는 "단장" 의 역할은 판매 주체 자체가 아니며, 주문 완료 후 판촉 수수료를 받을 수 있습니다. 일반적으로 이 부분의 마케팅 비용은 주문이 생성된 후 마케팅 담당자는 주문 비용 상세내역에서 이 비용 항목을 볼 수 있습니다. 주문이 정산될 때 판촉 커미션은 플랫폼 커미션과 함께 공제할 수 있으며, 그런 다음 플랫폼은 판촉 커미션을 홍보원에게 결산할 수 있습니다.

이런 지출은 노무보상으로, 플랫폼은 발기인을 대신하여 세금을 내야 할 의무가 있으며, 월별로 세율과 금액을 계산해야 한다. 따라서 일부 플랫폼은 매월 지정된 날짜에 각 판촉원이 결산해야 하는 세금을 계산하고 공제한 후 세후 금액을 판촉원에게 결산하는 월 결산 방식을 채택하고 있다. O2O, 온라인 렌터카 플랫폼 등과 같은 플랫폼도 있습니다. ) 그런 다음이 세금 부분을 부담합니다 (양털은 양에서 나옵니다). 주문이 결제될 때 판촉 커미션은 즉시 판촉원, 다음 달에 판촉원의 세금을 계산합니다. 플랫폼은 홍보인을 위해 스스로 세금을 납부한다.

플랫폼은 또한' 유연한 취업' 등 다양한 세금 계획 방식을 채택해 판촉원과 시간제 노동관계를 맺고 판촉원이 낮은 세율을 받을 수 있도록 할 수 있다.

플랫폼은 스스로 발기인을 위해 결제할 것이며, 당신은 은기업 직련, 지불 플랫폼 등의 기능을 사용하여 발기인을 대신하여 지불할 수 있습니다. 플랫폼 세금에는 발기인의 실명 정보가 필요하므로 개시자가 실명 등록 시스템 인증을 받아야 커미션을 받을 수 있다.

어떤 결제 방식을 사용하든 전자상거래 플랫폼은 주문 결제시 각종 비용 상세 (결제) 를 계산해야 하며, 결제를 담당하는 모듈을 청구 시스템이라고도 합니다.

전자상거래 플랫폼에는 상품, 상가, 범주, 마케팅 활동 등 다양한 공제 규칙이 있으며, 각종 판촉 공제도 있습니다. 공제 규칙 라우팅은 상품, 상인, 범주 공제 규칙 관리 배경과 같은 다양한 공제 규칙에 해당합니다. 기준 항목은 공제 대상, 공제 비율, 공제 라인, 규칙 유효 시간 범위, 규칙 상태입니다. 제품 관리자는 운영자와 공제 규칙을 확인하는 판단 논리가 필요합니다. 즉, 주문을 판단하여 주문에 적용되는 공제 규칙을 확인해야 합니다. 나중에 신규 공제 규칙을 추가할 때 이 공제 규칙 경로도 관리해야 합니다.

공제 규칙 라우팅은 각 전자 상거래 플랫폼마다 다르며 마케팅 활동, 주문/지급 고객, 구매자 신분, 공제 규칙 가중치 등이 포함될 수 있습니다.

일반적으로 주문을 생성할 때 공제 규칙 라우팅은 주문에 대한 정보를 기준으로 주문에 적용되는 공제 규칙을 판단하고 기록해야 합니다. 동시에, 판단을 위한 정보 요소를 증거로 보존해야 한다.

주문에 발기인의 참여가 있는 경우 주문을 만들 때 공제해야 하는 프로모션 비용도 계산하고 관련 발기인 정보를 저장 및 기록해야 합니다.

각 당사자의 하위 계좌 상세내역을 계산할 때 다음 사항에 주의해야 합니다.

일반적으로 주문 거래와 관련된 결제는 주문 상태가 최종 상태 (거래 완료, 환불 완료) 로 변경되고 주문 금액이 정산되지 않은 경우 결제 시스템에 결제 요청을 제출하는 것입니다. 몇 가지 해결책이 있습니다. 예를 들어, 주문 중 일부 화물이 먼저 접수된 것을 확인했는데, 먼저 일부 금액을 결제한 후 남은 금액을 결제할 수 있습니다.

번호판을 지불하는 대형 전자 상거래 플랫폼의 경우, 상인의 지불 속도를 높이기 위해 주문이 아직 확정되지 않은 경우 (예: 사용자가 입고를 확인할 때 또는 상인이 배송할 때) 상가에 대금을 결제할 수도 있습니다. 주문 결제 후 환불하면 상가 지갑에서 해당 금액을 공제합니다. 이러한 결제 방식은 플랫폼 측이 비교적 성숙한 위험 통제 능력을 갖추어야 하며, 위험 통제와 위험 이전을 통해 플랫폼 자금 손실을 방지해야 한다. 예를 들어, 상인과 계약을 체결하고, 상가 보증금, 상가&; 구매자의 위험통제, 상응하는 보상보험 구매 등.

거래 시스템이 결제 시스템에 결제 요청을 시작할 때 결제 지침, 결제 금액, 결제 유형 (전체/부분 결제) 등의 필드를 제출해야 합니다. 결제요청을 받은 후 결제는 실시간으로 또는 비동기적으로 할 수 있습니다. 예를 들어 업무량에 따라 x 시간마다 한 번씩 결제할 수 있습니다.

결제가 시작되면 청구 센터는 회계 시스템에서 주문에 대해 보류 중인 금액을 가져오고 결제 유형에 따라 결제 금액을 확인하고 확인 후 보류 중인 금액을 동결하여 청구 센터에 제출합니다. 청구 센터는 주문 스냅샷에서 공제 규칙을 찾아 상세 회계를 계산합니다.

청구 센터에서 각 측의 상세 장부를 계산한 후, 결산할 금액이 각 측의 상세 장부의 합계와 같은지 확인하기 위해 회계 센터와의 실시간 또는 준 실시간 조정이 필요하다. 감사 후 예산 명세서를 생성합니다.

대부분의 주문의 경우 결제 센터는 최종 자금 이체를 위해 결제 시스템에 결제 양식을 제출할 수 있습니다. 소수의 주문의 경우 결제는 수동 검토가 필요할 수 있으므로 결제 시스템에 제출하려면 검토가 필요합니다. 그렇지 않으면 결제가 거부되고 취소됩니다.

일반적으로 각 지사는 미리 지불 시스템에 계좌를 개설하고, 지불 시스템은 자금을 각 측의 자금 계좌로 결제한다. 지불 시스템의 경우 내부 계좌 간 자금 이체만 관련되며 결제 실패 경우는 드물다.

결제 시스템이 결제 성공 결과를 반환하면 결제 상태가 결제 완료로 변경됩니다. 결제 시스템은 거래 시스템 및 회계 시스템에 실시간으로 통보해야 하며, 회계 시스템은 각 계정의 자금 변동을 기록하고 계정 잔액을 갱신해야 합니다. 거래 시스템은 메시지 알림과 같은 관련 서비스를 트리거합니다. 회계 시스템이 있는 경우 회계 입력을 위해 비동기 통지 회계 시스템도 필요합니다.

성숙한 지불 회사의 경우 두 가지 시스템, 즉 회계 시스템과 회계 시스템이 있습니다. 두 세트 모두 회계 사용자 모델로 설계되었지만 회계 시스템이 업무에 직접 사용된다는 점이 다릅니다. 비즈니스 정보 흐름 잔액의 실시간 회계 및 업데이트와 함께 회계 흐름은 더 많은 거래 관련 내용을 기록합니다. 회계 시스템은 재무 회계, 일반 비동기 입력에 사용되며 엄격한 복식 회계법을 채택한다.

회계체계의 과목은 반드시 회계체계의 잎과목 아래에 있어야 한다. 두 시스템 간의 홈 모델은 다대다 관계를 갖게 됩니다. 이 회계 제도 체계는 계좌 (외부) 라고 할 수 있고, 이 회계 제도 체계는 계좌 (내부) 라고 할 수 있다.

복식 부기법에 따르면 일반적으로 자산 부채 손익 등으로 나뉜다.

거래의 본질은 각종 금액의 계좌 간 자금 이체이므로 먼저 해당 계좌를 만들어야 한다.

계정 설계는 고객, 계정, 계정의 세 가지 모델을 따릅니다.

고객: 자연인이나 기업을 가리키며 실명인증의 지불 계좌만 개설할 수 있습니다. 고객은 ID 번호를 고유한 식별자로 사용합니다.

계좌 번호: 로그인 계좌번호, 한 고객이 한정된 수의 계좌를 가질 수 있습니다. 즉, 신분증 한 장을 한정된 수의 계좌로 실명인증을 할 수 있습니다. 하지만 같은 지불회사, 신분증 한 개 아래 여러 계좌, 지급액 상한선은 * * * 입니다. 신분 인증 정보의 풍부함에 따라 지불 플랫폼의 잔액 계정은 1, 2 등급으로 나뉘며, 세 가지 최대 지불 금액과 권한은 20 만/년입니다. 잔액 인출, 위어바오 지불, 신용 지불에는 연간 제한이 없습니다. 은행 카드 빠른 지급 계약, 은행 카드 바인딩 추출 등의 작업도 계좌 번호를 기준으로 합니다.

계좌: 각 계좌는 결제 플랫폼 또는 전자상거래 사이트에 여러 가지 다양한 기능을 가진 계좌를 가지고 있습니다. 거래처에는 결제 계좌와 보증금 계좌가 있습니다. 구매자는 지불 계좌, 신용 지불 계좌 및 포인트 계좌를 가지고 있습니다. 또는 전자 상거래 플랫폼 측 내부 계좌 (예: 활동 보조금 계좌, 주문 보장 계좌 등) 입니다.

회계 핵심에는 주로 분개 입력 프로세스, 상세 원장, 상세 원장, 총계정원장 등 네 개의 표가 있습니다.

먼저 거래 코딩에 대한 분개 규칙 테이블인 분개 규칙이 필요합니다. 분개 규칙은 거래 코딩으로 구분되는 각 거래 시나리오가 발생할 때 회계 입력으로 분할되는 방법을 유지하는 규칙입니다. 예를 들어 거래 코드 100 1 이 주문 은행 카드 quickpay 로 정의된 경우 해당 주문의 지급 프로세스가 결제 플랫폼을 통해 회계 센터로 동기화되면 동기화된 거래 코드100/kloc-0 에 따라 동기화됩니다

거래가 발생하면 먼저 입력 흐름이 생성된 다음 구동 계정 잔액이 변경됩니다. 계좌 잔액이 변경된 후 상세 장부를 생성합니다. 하루가 끝나면 입력 프로세스에 따라 총계정원장을 생성합니다. 업무 필요에 따라 비동기적으로 분개 입력을 생성하기 전에 계정 잔액을 수정할 수도 있습니다. 그러나 회계 입력을 생성하든 버퍼링 회계 입력의 비동기 생성을 생성하든, 분개 입력과 상세 계정 잔액의 일관성을 보장해야 합니다. 이는 일말 시스템 검사에 의해 보장됩니다.

매일 먼저 결제 채널을 조정한 다음 회계 시스템과 회계 시스템을 조정해야 한다.

해야 할 일:

오류 처리는 두 가지 효과를 달성해야 한다. 하나는 조정을 완성하는 것이고, 다른 하나는 장부의 균형을 맞추는 것이다. 일반적인 회계 처리 방법에는 미정산, 게시 및 조정이 있습니다.

보충 주문: 인터페이스를 통한 주문 상태 수동 개입과 같은 수동 개입을 통해 기존 업무를 계속합니다.

장부: 불공평한 계산서에 대해서는 먼저 잠시 멈추고, 조사하여 처리하세요.

부기 (Bookentry): 가상 자금이 한 계정에서 다른 계정 (원본 증빙서) 으로 이체되는 부기.

1, 초과 청구

초과 지급에는 크게 두 가지 상황이 있다. 하나는 비동기 통지를 받지 않고 주문을 우선적으로 보충하는 것이다. 다른 하나는 같은 주문서를 두 번 지불하고 일반적으로 게시 방식으로 처리하는 것이다.

2. 단기 계좌

기본적으로 나타나지 않으며, 일반적으로 서명 거부 메커니즘을 통해 제 3 자 처리에 협력합니다. 조정 후 수동으로 명세서를 추가하여 계정의 균형을 맞추다.

3. 금액이 일치하지 않습니다

발생 확률은 매우 낮으며, 일반적으로 전자 상거래 플랫폼 내부 계산 오류입니다.

먼저 이 버그를 해결한 다음 조정 취소, 시스템 수정, 조정 전 계정 명세서 금액 등 비정상적인 순서로 처리합니다.